ROM API for nor Flash Hangs

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

ROM API for nor Flash Hangs

Jump to solution
389 Views
briancarrigan
Contributor I

I am experiencing an issue with the ROM API for nor Flash programming on the IMXRT1061. My application runs entirely in OCRAM, but I have SPIFlash for booting and storing configuration data. For convenience, I have divided my SPIFlash into three sections with 64KiB sector boundaries: the boot loader (at location 0, obviously), the Application, and the Configuration data. The boot loader is 2 sectors, the Application is 4 sectors, the config data is 11 sectors. I can reprogram these sectors via USB-HS link which works most of the time. The problem is that when I am programming the large section, it may hang  during one of the API Erase commands, after some number of sectors programmed. I found that if I "slow down" the sequence, by putting print statements to the console (serial UART, 115.2K baud), then the hang is avoided, although perhaps not eliminated. The watchdog does not reboot the CPU in this case, likely because the Erase command is retriggering it. Has anyone else encountered this issue, and is there a definitive way to ensure that it will not happen?

0 Kudos
1 Solution
257 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @MultipleMonomials ,

 

This just applies for HAB API, and OCRAM2 is also part of OCRAM, so the description is correct.

Hi @briancarrigan ,

 

I confirmed with the expert, the ROM Erase API doesn't trigger any watch dog at all, not sure if your application had enabled it so your solution fixed this issue, please kindly clarify.

 

Have a great day,
Kan


-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

 

Have a great day,
Kan


-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

View solution in original post

0 Kudos
6 Replies
373 Views
briancarrigan
Contributor I

It turns out that if I do a watchdog service immediately prior to calling the API Erase function, then it seems to complete without hanging. This is not a definitive solution, since testing small sample sizes on a prototype bench does not prove the general case.

0 Kudos
300 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @briancarrigan ,

 

Have you checked if the following OCRAM space was not occupied by your application? 

Kan_Li_0-1712800326675.png

You may refer to the chapter 9 system boot in the RM for more details.

 

Hope that helps,

 

Have a great day,
Kan


-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

 

0 Kudos
285 Views
MultipleMonomials
Contributor III

Hi!  I saw this post and it gave me some concerns, as we are using the ROM API in our product and have not reserved this RAM region.  Two questions for clarification:

  1. Could you confirm that the OCRAM region has to be reserved if you (only) use the ROM API for programming flash, as opposed to for the HAB API?  (this would mean that the text of the reference manual is incorrect and should be updated)
  2. The above figure gives the address range of 0x2020_0000-0x2020_7FFF, but this address range is actually in OCRAM2 on MIMXRT106x, not OCRAM.  Could you confirm that this is correct (meaning that this address range above is correct even though it isn't actually located in OCRAM)?

Thank you, hope this makes sense!

0 Kudos
258 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @MultipleMonomials ,

 

This just applies for HAB API, and OCRAM2 is also part of OCRAM, so the description is correct.

Hi @briancarrigan ,

 

I confirmed with the expert, the ROM Erase API doesn't trigger any watch dog at all, not sure if your application had enabled it so your solution fixed this issue, please kindly clarify.

 

Have a great day,
Kan


-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

 

Have a great day,
Kan


-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

0 Kudos
177 Views
briancarrigan
Contributor I

For informational purposes, I determine that my application and data reside entirely in OCRAM- FlexRAM, of which I use about 25%. I do not use the OCRAM2 at all. I have also enabled the watchdog timer, but for some reason the API Erase function timeout did not cause a reset of the processor; it just hung. I tested the WDOG function by coding an infiniloop, and it reset the processor as expected. This is still mysterious, but the project can continue with the fix to trigger the WDOG immediately prior to the API Flash Erase call. Perhaps it is also necessary to trigger immediately prior to other API calls as well, and for robustness, I will be doing this.

0 Kudos
130 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @briancarrigan ,

 

Thanks for the information! Since you have also enabled the watchdog timer, the reason why it hang the MCU during the API Erase process might be due to the flash has been erased partially at that moment when the watchdog timeout, the MCU does reset by watchdog but it could not locate the image as the beginning of the whole flash should have already be erased before the watchdog timeout event, so it comes to serial download mode finally , and looks like "hang" in your case. 

 

Hope that make senses,

 

Have a great day,
Kan


-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

0 Kudos