2394409_en-US

[#1]

Pit interrupt runs in ram wen flash erase

I found that I cannot enter the timer interrupt while erasing flash. To meet my requirements, I plan to run the timer interrupt in RAM. I modified the linker_flash_s32k388.ld file to place IntCtrl_Ip.o and Pit_Ip.o in RAM, but when I erase flash, I still encounter errors due to the arrival of the timer interrupt. Please tell me what details I have overlooked.#s32k388

Re: Pit interrupt runs in ram wen flash erase

Hello,

Simply placing IntCtrl_Ip.o and Pit_Ip.o into RAM is usually not enough. During a PFLASH erase operation, the CPU must avoid any access to the affected flash array.

Please verify that the interrupt vector table, the PIT ISR, all functions called by the ISR, and any data/constants used by the ISR are also located in SRAM. Additionally, ensure that the VTOR register points to a RAM-based vector table. A linker map file is typically the best way to identify remaining flash accesses.

The S32K3 Reference Manual also notes that code execution must be moved to SRAM when flash operations require continued execution.

Best regards,

Peter

Re: Pit interrupt runs in ram wen flash erase

My ISR and the functions called by ISR have been placed in RAM, and the address of VTOR is also 0x2... rather than 0x4... My flash driver chose to run in RAM during configuration in RTD. It runs normally as long as the PIT is closed, but it freezes when the PIT is enabled, but I cannot trace where the problem is through debugging

Re: Pit interrupt runs in ram wen flash erase

Hello,

its hard to judge from the description.

Things that are commonly overlooked:

1. Interrupt vector table is still in Flash

   • The CPU first fetches the ISR address from the vector table.
   • If the vector table remains in P-Flash, the interrupt will still access Flash during erase.
   • The vector table must be copied to RAM and VTOR updated accordingly.

2. The PIT ISR function itself must be in RAM

   • Not only the PIT driver (Pit_Ip.o) but also the application callback/ISR.

3. Everything called from the ISR must be in RAM

   • Application functions
   • OS services
   • Scheduler hooks
   • Logging/debug functions
   • Any helper functions invoked by the ISR

4. No Flash-resident constants

   • Even if the code executes from RAM, accesses to:
     • const tables
     • calibration data
     • string literals
     • configuration structures can still result in Flash reads.

5. No Flash accesses by the stack trace/debug infrastructure

   • Debug builds often introduce unexpected Flash references.

Best regards,

Peter