How to implement non-blocking data flash erase functionality ?

[jani12]

Our project is Advanced Drive Assist Sytem (ADAS) Controller. This embedded controller is based on Renesas RH850 / U2A16 Microcontroller. Our design is based on Autosar RTOS by ETAS. Our software architecture is basically Application Software and low-level software. We are using WindRiver Diab Compiler version 5.9.6.6 to compile 'C' language code.

Application software calls low-level software API to erase data flash in non-blocking manner. Typically, the way non-blocking functionality is implemented is to create a special purpose non-blocking task in the RTOS, which has lower priority than all the other time-based rtos tasks. Non-blocking API simply writes some variables to set up a non-blocking operation, and then the operation is actually carried out in the special purpose low priority task. The only tricky thing with this design is that the application software requests non-blocking erases during the power-down procedure, after Application software have disabled all tasks and interrupts - so care must be take to ensure the special-purpose non-blocking task does NOT get disabled during controller shutdown.

Following may be some options for implementing non-blocking erase functionality:

• During shutdown all tasks and interrupts will be disabled. This means from background task application software will call low-level API to erase data flash. Just FYI, RTOS autostarts background task after application software is initialized. Background task is controlled by application software. Background task never returns. The API will write few variables to setup erase operation. Can the actual erase operation functionality be in the background task? One advantage is that background task isn't disabled during shutdown. Some of the disadvantages may be when application software calls API to find out if erase has completed. The operation that checks erase complete functionality will be in the background task and it is unknown how often this operation will execute in the background task. The API that is called to get erase status and code in background task that fetches the erase status from data flash might not be synchronized.
• What might be some issues with implementing erase functionality in Interrupt Service Routine (ISR) ?
• What are other options?

Mainly, I'm interested in knowing whether erase functionality can be implemented in the background task ?

 

[Diver300]

Depending on the microcontroller, the erasing of the flash may interrupt the program flow.

For instance, in the 16 bit PIC microcontrollers, it says:-

Flash memory can be programmed in two ways:
• In-Circuit Serial Programming™ (ICSP™)
programming capability
• Run-Time Self-Programming (RTSP)

A complete programming sequence is necessary for
programming or erasing the internal Flash in RTSP
mode. The processor stalls (waits) until the
programming operation is finished.

so it's not possible to be completely multitasking during flash erase or programming. In many ways that makes sense because the program itself may be being erased / written, and it would be bad for the processor to jump into the middle of an area of program memory that was in the process of being erased or written.

Now the time taken to erase or program the flash will not be large. It may only be a few ms, so it may be possible to fit in the programming task without disrupting anything else, but it is very dependent on what else is going on. Writing to flash usually has a limit on the number of times that it can be done, maybe 1 million, so that won't be happening all the time, and some compromises can be made, like not starting the erases / flash unless the voltage is normal, and not bothering to measure the voltage for a few ms after that won't matter.

In your situation, you may be stuck with what ETAS's operating system lets you do. It takes some careful design to decide if a few ms of pause is acceptable. In many cases it is, because peripherals, such as the CAN engine, will take care of sending previously queued messages or receiving new messages while the processor is stalled. However, a fast loop that is looking at inputs that may be transitory would not survive a few ms pause. The result might be that the RTOS just bans flash programming during run time.

Even if the processor is capable of programming the flash without stalling, the RTOS may have a blanket ban on such operations. The 'C' compiler may have certain ways of doing things which makes it more difficult to manage the short processor pauses.

A lot of automotive modules will write to flash on shutdown. Modules that have sleep mode can write to flash when all the stuff that interacts with the rest of the vehicle have finished. Modules that are de-powered can have a capacitor large enough after the power goes to keep the processor alive long enough to erase / write the flash. That avoids most worries about processor pauses so ETAS may have provided that one option alone for flash erase / program.