Recovering from wrong W25Q QSPI flash chips (?)

[mjbcswitzerland]

Hi All

Using the W25Q devices (with part ending IQ) existing products have been build and used successfully.

However a batch have been produced where the IQ ending parts are incorrectly configured (without the QUAD mode setting being active) and so they won't boot - can't be programmed - due to the fact that they are in single data line mode.

There is no JTAG access on the HW so a way to recover these board is being searched for, requiring the Q bit to be programmed in the status register without needing to remove the devices from the boards.

What is suggested to solve this problem?

Regards

Mark

[Masmiseim]

Hello Marc,

can you access the board via MCUBootUtility/blhost?

Regards?

[mjbcswitzerland]

Hi

Yes, I can access like that but don't know how it can be used to change the chip's configuration.

I have also had a problem with it in the past when protecting the start of the QSPI flash (against erase/writing) and then the utility also didn't work because it couldn't write.

Regards

Mark

[Masmiseim · Accepted solution]

Hello Mark,

never tried it myself, but theoretically it should work, maybe you have to use blhost directly without the nice MCUBootUtility GUI.

You could load an application to the internal RAM and execute it. This Application could reconfigure your QSPI flash.

This is basically what MCUBootUtility is doing to write to the external flash. The flash-loader is loaded to the internal RAM and executed. MCUBootUtility sends the binary which should be written to the flash-loader. The flash-loader will do the actual writing of the binary to the flash.

Regards

[mjbcswitzerland]

Hi

I have a solution to program i.MX RT via USB-host which I completely forgot about (at least forgot the details). I have code that I load to the device in ISP mode (using the SDP commands as used also by the MCUBootUtility) that subsequently runs in RAM and re-enumerates as a USB-CDC device that accepts SREC content. This allows using one i.MX RT as USB-Host to program other i.MX RT devices in the factory.
That means that all I need to do is change that program to first check the QSPI flash status and reprogram it if needed.
It is 7 months since I developed it and had forgotten that it was loading code to RAM and not just doing the programming directly via  SDP commands.....

Problem solved!

Thanks and regards

Mark

P.S. Below is a pic of the programmer - it uses an IMXRT1050-EVB with display as master and the board to be programmed and tested is inserted onto the bed of nails at the bottom. When detected by the master it powers it up and checks all voltages and programs Kinetis parts (on the same board via SWD) before setting the i.MX RT on the target board to ISP mode and programming it via USB (first USB-HID to load the programming code and then USB-CDC to program the image).
In addition it also programs a WiFi module on the target via USB (whereby the now operating i.MX RT works as USB-SPI bridge). It programs time and date and manages serial numbers and MAC addresses and logs all details on a SD card for traceability.

Some time ago I started a document about how it could be done: https://www.utasker.com/docs/iMX/uTasker_iMX-RT-Programmer.pdf but, although the programmer was completed, the document wasn't - but the details (see appendix) are still about right. Unfortunately my memory completely let me down in this situation but now it is all coming back again....