IRQs while erasing a page of flash. STM32

[marknorman9]

Posted on November 19, 2009 at 13:36

IRQs while erasing a page of flash. STM32

[tomas23]

Posted on May 17, 2011 at 13:30

Sure. The FLASH write access stalls the FLASH controller until the write operation is finished. Unlike our older ARM MCUs, STM32 stalls the I-code bus (and consequently CPU) without loosing track of the valid instructions and will continue as soon as programming/erasing is over.

If you want a code running during these operations, do it in RAM, with IVC remapped to RAM, too. The 40 ms, according to the DS, is correct time for mass erase.

[marknorman9]

Posted on May 17, 2011 at 13:30

I have written upgrade code that divides the flash into sections. The running application in one section can write a new load, which is transfered using I2C into another section and then jump into new load. Although I had to remap the IVT as it comes in it seems to work successfully :D . However,when I stress tested it it appeared to lock every so often and I can see that this happens during a page erase :-|.

Now I read that the address bus stalls for any code running in flash when a page in that flash is being erased, and this can last upto 40ms. Does anyone know how the processor copes with getting a vector from the IVT when it is in the flash, during an erase, as I'm guessing this maybe what is causeing it. Can I just disable interupts or will I have to do something clever like copy the IVT in SRAM and remap to tempory ISRs to buffer the IRQs? If disaling the interupts will do, what is the best way? Thanks

[armmcu]

Posted on May 17, 2011 at 13:30

Well observed Mr edison !

[marknorman9]

Posted on May 17, 2011 at 13:30

Thank you

Could you tell me what will actually happens to interrupts that come in during this stall, are they or can they be buffered in any way if I leave my IVT in the flash? BTW if the ICode bus stalls is any ram code run using another bus and if so how is bus switching done, so you can jump in and out of RAM and FLASH execution threads? First question is more important to me.

[marknorman9]

Posted on May 17, 2011 at 13:30

anybody out there out any answers on this please?

[armmcu]

Posted on May 17, 2011 at 13:30

There is no a mechanism embedded inside to buffer Flash instructions fetches during interrupts. So for sure you will lose interrupts during the Bus stall period if you leave your IVT in the flash.

I guess remapping just IVT into RAM is enough to recover since interrupts will be pending on the NVIC and you will not lose interrupts. If both IVC and IVT are executed from RAM your application will be more deterministic.

[marknorman9]

Posted on May 17, 2011 at 13:30

IVC?

[armmcu]

Posted on May 17, 2011 at 13:30

I mean the interrupt vector code (interrupt routines)

[marknorman9]

Posted on May 17, 2011 at 13:30

So the vector will need to point to a routine in ram instead of Flash, and that routine will need to manage those interupts. Um tricky. But I guess my ISRs should be slim enough to do that if they are written properly, in theory they should not call any library routines, just talk directly to registers and ram. I have to check this out. I was thinking of going down this avenue if I can not get away with losing some interupts.

But the main thing I want to establish at the moment is, can the interrupt controller ''keep its head'' if it can not retrieve the vectors from the stalled flash? I'm hoping it will not lock up, but just through away the unprocessed interrupts and then recover later when the flash is back. Do you know the answer to this?