PIT timer exception when erasing flash chip

[estacey]

We're using the RT1021 MCU and our application needs to keep a timer interrupt running even while programming the flash chip.  I moved my interrupt handlers into RAM and even the drivers just to try and avoid bus errors.  I'm getting exceptions when I get PIT timer interrupts anyway.    Why would these be occurring with interrupt handlers in RAM?  The handlers don't execute code in the flash chip.  Does it make sense that I would have to disable ALL interrupts in order to erase or program the flexspi nor chip?  Is there some lower level code being linked in for interrupts?  Could it come down to the NVIC not being in RAM? 

Also, probably unrelated, the debugger shows ReprogramSector in the call stack but gives the line number for the Test_Flash routine and displays that code.  I thought maybe the stack was getting clobbered, but it looks like a debugger error.  The offset in the map file indicates ReprogramSector is at that address. 

Thanks in advance for any insight,
Ellen

[estacey]

Mark,

So to be clear, I need to get startup_mimxrt1021.o into RAM?   I'm still getting the exception with that.  I see in the map file that now the other ISRs are in RAM but the .isr_vector is still in flash.  When I build with the project option to link to RAM, the vector gets put into RAM, but my project won't fit.  There has to be a way to get the vector into RAM without requiring everything to go to RAM, doesn't there?

[mjbcswitzerland]

Hi

https://community.nxp.com/thread/519775#comment-1274091 

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[estacey]

Ha!  This is exactly what I did last night after Raymundo's input. I guess that means I'm learning.  Thanks for the information.

[Ray_V]

You don't need to place everything on RAM.

Look at the ResetISR, usually it will set the VTOR to point to the Vector Table in Flash.

You can change the code so it will copy the vector table to RAM and then point the VTOR to that location.

You'll also need to make sure the location is **Correction** 128 byte aligned and that the linker will not try to use that RAM location.

You can do that by excluding that area from the RAM settings or by placing a NOINIT array where the vector table will be.

[Ray_V · Accepted solution]

estacey@avg.net‌ sorry about the wrong info. 128 byte alignment is the minimum for an M4 processor. However actual alignment depends on the number of vectors your table has. You need to round to the next power of 2.

For example, if your table has 68 vectors it needs 68x4 bytes so it needs 272 bytes. so the next power of2 would be 2^9 or 512 bytes, since 2^8 is 256 and you need more than that.

[estacey]

Thanks for the updated information!  I sectioned off 0x300 bytes off the bottom of ITC RAM and used that, then moved it to be after the larger ITC RAM segment in the list so my interrupt handlers would be automatically loaded into the larger segment.  Starting at zero surely is 512 byte aligned.  It seems to work great now!  Thank you so much for your help!

[mjbcswitzerland]

Hi

If you have errors due to an interrupt when performing Flash operations it will almost certainly mean that the interrupt is (still) accessing the flash. I would first step through the interrupt in disassembly mode, when running in RAM, and carefully watch all accesses to determine which one is maybe not in the RAM.

If you don't have a large application (above 192k) it is worth running it directly in ITC so that there are no Flash restrictions. Also you will achieve better speed, lower power consumption and lower radiation if you can do that.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[estacey]

Thank you for the tip.  I verified that no flash address is being accessed.  The interrupt couldn't be simpler.  It is a PIT timer that just increments a variable to count the milliseconds that passed.  The variable is in RAM.  fsl_pit.o is in RAM (probably not necessary), and the interrupt handler is in RAM.  I even commented out the PIT initialization and the problem goes away.  I still have to wonder if something else is accessing the flash to get the interrupt handler address. 

[mjbcswitzerland]

Ellen

Are you sure that the interrupt vector table itself is in RAM?

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[estacey]

That was my thought - that the access was happening between the timer firing and the ISR being called.  I chased down the NVIC to what I thought were internal core registers.  Please correct me if I'm wrong.

[mjbcswitzerland]

Ellen

NVIC is internal to the Cortex-M7 core but the interrupt vectors (pointed to by VTOR) can be anywhere - best in ITC since they are fastest there. If they are in SPI flash it will be your issue.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]