We have a custom MIMXRT1171xxxA_M7 board. i.MX-RT1170
Problem: We can't use segger J-link tool package 7.98d, but I can with 7.84b. But if I attempt to debug with 7.98d. It will be in a permanent locked state( I.e. We will not be able to debug, flash or erase using any J-link version after that). Fortunately this locked state can be unlocked by using the MCUXpresso Secure provisioning tool.
It has to be "un locked" using MCUXpresso Secure Provisioning tool Tools-> Flash prog
Running this script seems to take the board out of the unlocked state. And I am able to debug/flash the board without any problem.
rammer. And then it will prompt " It seems the external memory is not available. Do you want to configure it now?" and clicking "Yes" would run the ext_memory_setup.bat .
It seems that the following lines in the ext_memory_setup.bat has something to do about the unlocking the board.
call "%blhost%" %blhost_connect% -j -- fill-memory 0x2000 4 0xCF900001 word
call "%blhost%" %blhost_connect% -j -- configure-memory 9 0x2000
call "%blhost%" %blhost_connect% -j -- fill-memory 0x2000 4 0xC0000007 word
call "%blhost%" %blhost_connect% -j -- configure-memory 9 0x2000
The after this I can see that the image I flashed into QSPI before the debug attempt is still intact and it even executes after running the ext_memory_setup.bat.
That image will not execute even after power cycle it we did not run ext_memory_setup.bat after debug attempt with new version.
In the reference manual there is information about the configuration 0xc0000007 (QuadSPI NOR - Quad SDR Read: option0 = 0xc0000007 (133MHz))
But there is no information about the 0xCF900001 configuration word. I would assume this is an option1 configuration but there are no examples for Option 1 configurations.
My Question:
So please help me understand what is causing the lockup. From my understanding J-link uses proprietary RAM Flash loader. But I am unable to understand how that causes persistent corruption(even after power cycle) of the configuration that causes the board to be unable to be debugged or even start the previously flashed application if we tried to debug/flash with 7.98d. From my understanding for a persistent corruption the eFuses and the QuadSPI flash has to be corrupted/altered. And how can ext_memory_setup.bat fix this alteration. Please help.
QSPI Nor flash interface information is below
We have efuses set for for XIP on NOR Flash without OTFAD.
Hi @kasun
Thank you for reaching out!
As you mention the Segger FW loads their own flashloader and it will initialize the flash memory for R/W operations. Their flashloader is called SEGGER Flash Loader and its dedicated wiki is here : https://wiki.segger.com/SEGGER_Flash_Loader
I do not know the differences between releases 7.98d and 7.84b and perhaps it is better to check directly with Segger on this. Based on my understanding, if you are able to check the source code for each source code, it will be easier. I It migth be that configuration performed by release 7.84b configuration for flash memory, or even MCU pins is causing the MCU to brick. I wonder if this brick is only related to SWD access or if even the application is not even to boot.
We have this application note AN13567
Optimizing Flashloader Download Speed on RT Platform with JLink, and it discuss about optimizing Segger flashloader speed and important concepts regarding their API. The AN refer to the flashloader as Segger's open flashloader the https://wiki.segger.com/Open_Flashloader I mention this to you , as it brings the opportunity to control the operation of the flashloder.
In fact, I use to recommend your recovery method, almost all the time, since when the MCU bricks , changing the boot mode to serial downloader, helps to regain debug access. In serial downloader mode the bootROM takes control, and it does perform always the same pin setup and gets the processor into a known state.
The Secure Provisioning Tool uses bootROM APIs to discover the SFDP parameters of flash memories. The 0xC0000007 is given as a parameter for the bootROM APIs, called config option0. The easiest way to discover their paramters is using the SPT's Boot Memory Configurator.
However, 0xCF900001 is not config1. You can check this by enabling Has option1, in purple. There are no numbers releated. This is FlexSPI NOR memory instance using option on address 0x2000. The last number of 0xCF900001 is the instance of FlexSPI, it will be two if you are using the other FlexSPI instance. I you need, I can investigate the meaning of the other parts of this word.
Anyway, I recommend to check also with Segger, and if you like you can create your own flashloader algorithm/ image.
I hope this helps,
Diego
