in my setup I use a KL17Z64 that receives bytes via UART (interrupt driven) and depending on the value sometimes writes a few bytes into a ringbuffer in the FLASH.
I've read so far that during a flash write operation other flash reads (e.g. executing an interrupt from flash) are not allowed, since the KL1764 only has one flash block.
In order to avoid this I first tried disabling interrupts before the CCIF bit in FTFA_FSTAT is cleared (by software) and enabling them again after the bit is 1 again (set by hardware after flash write completion).
But this is rather inconvenient since sometimes UART bytes get lost because the interrupts are disabled too long (especially when I erase a flash section so I can reuse it)
Then I further read that an alternative would be to store the UART ISR in SRAM, so it can be executed while the flash write operation is in progress.
I did this by giving the ISR the attribute __attribute__ ((section(".custom_ramfunctions"))) and adding *(.custom_ramfunctions) after *(.data*) in the .data section of the linker file. Additionaly I defined __ram_vector_table__ so the vector table is also in RAM. This (without writing the flash) seems to work since the ISR is still executed and when I use my debugger I can see the PC somewhere in the SRAM. Additionally I moved the clearing of the CCIF bit and the loop until it's set again into the SRAM as well (since I think this is the only clean way to actually write the flash when you only have one flash block?).
However, if I combine the ISR and the flash writes I sometimes get a reset due to a core LOCKUP event.
I don't understand why this happens, since I only read RAM while the flash write operation is in progress. Did I forget some important step?
Is there any way to find out what exactly cause the LOCKUP event? Or does anyone have a small working project with both flash writes and interrupts from RAM?
For now it might be sufficient to drop some bytes, but I hope that I can actually do this in a cleaner way.