Program freezes after I erase the NOR Flash

[tilblackout]

I am developing a product based on I.MX RT1170 from NXP, which requires an external NOR Flash connected to its FlexSPI interface.This way,the NOR Flash is mapped to the CPU's memory. Subsequently, the program can run in the NOR Flash.

Due to project requirements, I need to use memory starting from 0x60C00000 to store some data, and I need to erase about 1M of memory.However, after erasing this memory, the program freezes after a while, and sometimes it directly resets.

The program doesn't freeze during the Flash erasure process. Instead, it usually occurs after calling my erase function (erasing 1M in size) and running some simple code afterward, such as printing "Hello, world." The likelihood of the program freezing in this scenario is minimal. However, if more complex code, similar to LwIP, is executed subsequently, the program is more likely to freeze.

Here is a brief description based on my implementation:

• the size of the program I wrote is less than 0xC00000
• I disable interrupts before executing the Flash erase functions.
• If the program is executing in NOR Flash, the Flash erase functions cannot be placed in NOR Flash. This would lead to errors in Flash. Therefore, we typically link Flash functions to RAM. However, I am using the ROM API (which executes the chip's built-in ROM BootLoader from Flash after power-up, providing Flash APIs), ensuring there are no conflicts as mentioned earlier. I also attempted to implement Flash erase functions myself and link those files to RAM, but the issue of program freezing persisted.
• The same Flash erase code works fine on two other products using the RT1170 chip (same Flash model and connection).

Additionally, if I link the program to run in RAM, there are no issues. So, I suspect that erasing the Flash is causing an error when the subsequent chip tries to fetch code from NOR Flash.So this seems to be a hardware issue, but I haven't made any changes to the NOR Flash circuitry, and the rest of the system has no issues before I perform the Flash erase.

I am completely puzzled by this problem.Could you provide me with some ideas?

[tellurium]

Would it be possible to attach a debugger and see where exactly it freezes?

[tilblackout]

Would it be possible to attach a debugger and see where exactly it freezes?

The occurrence of the system freeze is random and closely related to the overall program structure.
For instance, if the subsequent code involves a simple "hello world" output with a one-second interval, the likelihood of a freeze is low, around 10-20%. However, if the subsequent code is more complex like LwIP, the freeze probability is nearly 100%.

Sometimes it freezes, and other times it resets directly. Occasionally, it gets stuck in the Flash function, sometimes in FreeRTOS, and at other times in LwIP. Therefore, I believe the state during the freeze has little reference value. It is likely that there is an issue with the subsequent CPU fetching instructions from NOR Flash.

[macboy]

I did some Flash drivers a long time ago, and it is not as simple as most devices, especially if you are running code from Flash too. Each erase or write takes time, and the flash can't do anything else during this time, especially reading executable code. There are two fundamental ways to deal with the flash busy time: issue the write/erase then wait for not busy then return to caller, or wait for not busy then issue the write/erase then return to caller. The benefit of the latter is that the CPU is able to do other work while the flash is busy, but critically, nothing else can touch the flash during this time, including fetching CPU instructions. The former is safer since the Flash API function doesn't return to the caller until the flash is ready to read. It is the only way to do it if you are executing the calling function from Flash. You may need to investigate the behaviour of the flash API you are using.

[pgo]

One thing to check would be that any caches have been flushed after doing the flash programming.
I'm am not familiar with the chip so this may not be relevant.

bye

[tilblackout]

Thank you all for your responses. The issue was related to limitations in the Flash ROM API provided by the RT1170 chip. The manual indicated that a specific clock source must be used when configuring a certain field. After changing one clock source, the issue was resolved. It's puzzling because the other two PCB boards using the RT1170 chip, with the same Flash model and connection, didn't experience any freezing issues. I didn't suspect many software issues throughout this process. However, it's resolved now, and I am currently seeking further details from NXP official technical support.