FLASH_Program() and IO interrupt crashes

[joao_ribeiro]

Hello,

Are the FLASH_Program() FLASH_VerifyProgram() FLASH_Erase() FLASH_VerifyErase() functions sensitive to a IO interrupt call while being processed?

We have a project were we have a bootloader and an app running together. Both share a memory zone at the address 0xFF000. Also the app has a zone of memory that we reserve for a nonvolatile values at 0xFC000. The interrupt vector is at SCB->VTOR = 0xF000 therefore the app starts at the address 0xF000.

Our project has 10 IO interrupts that can be randomly triggered by sensors. We found that our system crashes if we run a save command (running the FLASH_Program functions) and an sensor event is triggered at the same time. After finding this correlation between the save command and the sensor event, we introduced a IO interrupt disable before the FLASH and a IO interrupt enable after it. The crashes stopped.

Is it right that when running the FLASH_Program function no IO interrupt can be triggered? or do we have other problem that is being masked by it? By our testing it seems related, but it would be nice to have more info on that and some confirmation.

Thank you for the help

Regards

[ErichStyger · Accepted solution]

It might depend on the device, but I have to disable interrupts during flash programming for Kinetis devices. This is actually true for most devices I'm aware of, unless the programming routine disables the interrupts internally.

[joao_ribeiro]

Hi ErichStyger,

Thank you for the reply.

We are using the Kinetis K64.

I fill more confident reading from your reply now.

But on that idea, should all interrupts be disable prier to the FLASH_Program function and not only the IO interrupts. We are now disabling the IO interrupts before flash but we have also timer interrupts and serial comm interrupts. Maybe we should be using the DisableGlobalIRQ() rather then the DisableIRQ(GPIO_1_IRQN) individually. is that correct?

Thank you once more for the help.

[ErichStyger]

You should consider disabling all interrupts.

The thing is this: typically during flash programming, the flash memory is not available/accessible by the MCU. If now an interrupt happens, the interrupt controller needs to access the vector table (usually in flash) and then jump to the vector/ISR function (usually in flash too). So you have to prevent this, and the usual way is to disable interrupts.

Now if you have the interrupt vector table & ISR code in RAM, then usually this is available and you can keep the interrupts going. Or you have the vector table plus the ISR in another flash area (different flash controller), then you should be able to continue running interrupts too.

I have used mostly the K22 (until it was not available any more), and there I have disabled all interrupts. You can see the implementation here:

https://github.com/ErichStyger/McuOnEclipseLibrary/blob/master/lib/minIni/McuFlash.c

But you find other examples in the NXP SDK too.

I hope this helps,

Erich

[joao_ribeiro]

Thank you very much for the answer. 

It makes complete sense now.

We are now more confident with the fix. Also the flash only occurs when a new configuration is sent and it is not that often to happen.

Thank you once more for the help.

Regards