PE Internal Flash driver causes core lockup

[tmeyer]

Hi,

I am using the Processor Expert IntFlash component for the KE04 processor. (KDS 2.0.0).

The issue shows up when UART interrupts are being serviced within a SetBlockFlash() call(512B of data). I was able to fix the core lockup issue by disabling/enabling interrupt around this call, however I then miss the UART data coming during this write period.

Is this a known issue or am I using it improperly?

Any help would be appreciated.

Thanks,

Tim

[emanuelemarracc]

Dear Mark,

thank you for your answer.

I'm working in Run mode and MK66FN2M0VMD18 features only  2MB program flash memory bank.

I need to store program code in the first half and data for update purposes in the second half. What I need to do is:

1. erase second half and write update data

2. erase first half and copy data from the second half.

Do I need to use program memory swap mode? Why running Interrupts may cause an error when accessing the flash bank?

Pleas note that on the ARM Community we read that a delay is required between calling the erase/write handler function and carrying out flash commands to prevent core lockup "

Writing Data To Flash During Program Execution With The Freescale KL25z Series. - Embedded blog - Em... 

Can You explain why this delay should be useful for our aims? How to dimension the delay?

Best Regards

Emanuele

[mjbcswitzerland · Accepted solution]

Hi Tim

Interrupts need to be disabled when programming Flash if they run in Flash. If you can put the interrupt routine in SRAM you won't need to disable interrupts when programming and so won't lose UART data (due to rx overruns).

It is often not very practical to put large amounts of code in SRAM so you may need to reduce the Baud rate used so that there is no overrun during each programming operation.

Make sure that the disable/enable interrupt is not placed around the complete block call but only around the actual programming operation (block programming of 512 bytes will take several ms whereas each individual programming operation will be taking about 100us to complete). It should be possible to work with a Baud rate of up 38'400 without underruns during programming.

Since sector deletes take longer, deleting should be avoided during UART activity if at all possible, if the interrupts cannot be relocated to SRAM.

This is a 'normal' restriction of these devices.

Regards

Mark

P.S. If you can use a flow control protocol (XON/XOFF or RTS/CTS) on the line you can also stop the remote transmitter from sending any data while programming/deleting.

http://www.utasker.com/kinetis.html

[tmeyer]

Hi Mark,

Thanks for that info. I am looking into designing the system to prevent rs485 data to be on the bus during flash erases/writes.

Tim

[emanuelemarracc]

Dear All,

I'm using Kinetis MK66FN2M0VMD18 on a Custom Board and I'm facing the same troubles when I'm attempt to write or erase flash memory.

I cannot disable interrupt when I'm operating on flash because of the behavior of my application.

I'm not sure that disabling interrupt will resolve my problems but  at the same time I don't have any other valid solutions.

Could You explain me why disabling intterupts when executing flash commands should be the solution to this issue?

Is there any official document by NXP asserting this solution?

Thanks for Your support,

Best Regards

[mjbcswitzerland]

Hi

There are multiple flash banks in the K66 and as long as your code is not running (and no interrupts need to run) in the Flash bank being erased/written there is no difficulty.

Regards

Mark