iMXRT1064-EVK; how to fix corrupted internal FLASH

[jaripeltonen]

Hi,

I'm developing SW for iMXRT1064-EVK. I'm using MCUXpresso as development tool. At some point my HW crashed and now I am not able to recover it. MCUXpresso notifies that it cannot communicate with the HW when I try to initiate a Debug session. I had similar kind of crash issues earlier, but I was able to recover the board by programming a demo SW image into it by using NXP Secure Provisioning Tool. This time the crash is more severe and the tool does not do the trick. So, I took the MCU Boot Utility tool and tried with it, but no luck. I tried to check if something is wrong with the FLASH and I found out that there are sections that I cannot erase. For example, address ranges 0x0..0x12000 and 0x200000..0x230000 contain some data, but I cannot erase those areas. However, I can erase other areas of FLASH. There are no issues in reading the memory contents with MCU Boot Utility tool, writing/erasing is the issue.

Does anyone know a way to make the FLASH operational again? Maybe, for some reason, a Sector/Block Lock bit is preventing erasing. Does anyone know a trick to access the internal registers of the FLASH (W25Q32JV)? Using "blhost" maybe? I would appreciate if you could give some hint or advice in getting my HW alive again. Thanks!

Best Regards,

Jari

[jeremyzhou]

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
According to your description, it's able to enter the Serial Downloader mode now.
1) Does anyone know a trick to access the internal registers of the FLASH (W25Q32JV)? Using "blhost" maybe?
-- No, I'm afraid that the "blhost" is incapable of doing that.
So in firstly, I'd like to suggest to share the log message when using the MCU Boot Utility tool to erase the areas of 0x0~0x12000 and 0x200000~0x230000 (just like the below shows), as it can tell us what problem it may be.
Looking forward to your reply.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[jaripeltonen]

Hi Jeremy,

Thanks for your message! As I replied, I seem to have fixed the issue.

I did not copy the error message from the log output, but if I remember it correctly, it was indicating invalid memory range (error code 10200 ?).

Best regards,

Jari

[mjbcswitzerland · Accepted solution]

Hi

Maybe the QSPI flash has some sectors write protected (?)

When I started working with the i.MX RT parts and developed the uTasker boot loader concept I would protect the loader in the SPI flash devices but I found that the MCU Boot Utility can not handle this case and so I needed to un-protect the devices before I could use the tool to reprogram the board. Fortunately I had an un-protection mechanism in the code (for safety reasons) that I could command and so recover the boards and so I didn't have to try other methods.

If I were in your situation I would try loading code with MCUXpresso (after setting the DIP switches to allow it to start in the ISP mode, otherwise the debugger may not be able to connect) that loads and runs from SRAM. This code can check the status register of the QSPI device and un-protect it if needed.

Finally, the i.MX RT and the debuggers are difficult when there is run-away code since it is often not possible to connect the debugger again without first deleting the flash or loading a known-good code. MCUXpresso is especially bad at this and so I tend to use IAR instead since its debugger operation is much more resilient (the free Kickstart edition is fine for such recovery work) - it is best to always have the possibility to pause startup code via an emergency input so that debuggers can connect - see also the chapter "What to do when things go terribly wrong" in the uTasker MCUXpresso build guide: https://www.utasker.com/docs/iMX/MCUXpresso.pdf

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or product development requirements

For professionals searching for faster, problem free i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1064.html

[jaripeltonen]

Hi Mark,

Thank you for your comments and advice on this issue! As I wrote in my original question, I am also suspecting some sort of write protection or sector block issue on the internal FLASH.

To make sure that I have understood correctly your proposal, this is what you suggest;

- an application needs to be implemented that checks status register(s) of the FLASH memory

- if write protection is found to be active, a routine to disable write protection needs to be implemented in the application

- the DIP switches on the EVK board should be set to Serial Download Mode

- the application needs to run from SRAM

Please confirm if these are the steps to take. Thanks!

Best regards,

Jari

[jaripeltonen]

Hi Mark,

Seems that I got my HW fixed! I'm not sure what was the actual step that did the trick. I downloaded the 'hello_world' demo application, ran it from SRAM and now I can erase all those problematic FLASH sections.

Thanks for your support!

If I end up in a similar situation and cannot sort it out by myself, I will open up a new thread. Now I'm happy to be able to continue my SW development on the EVK.

Best regards,

Jari