I am working on a OTA Firmware update for my boards, and I have to copy my flash functions into RAM. I run into the problem when running a RAM Function. If I step through the code by assembly instructions, I can get through the RAM function. If I don’t, my board resets. I am assuming a context switch or interrupt is messing with where the RAM function left off, and is causing a reset.
The RAM functions are copied to a declared global array that is of a fixed size. So I don’t think I have some scope problem.
I don’t think FreeRTOS itself adds any additional requirement over and
above what would have to be considered in a bare metal (no OS)
application. As you know, when you are writing to flash, in most cases
you cannot simultaneously read from or execute from the same flash -
hence your copying of the code to RAM. So you have to take care of
first ensuring your RAM functions can be relocated (compiler options, or
simply have the functions declared as RAM functions using any compiler
or linker extensions that permit that), and second nothing other than
the code you copied to RAM can execute for the duration of the write to
flash - and that will mean ensuring no interrupts can execute unless you
move the vector table and handlers to RAM too. The RTOS has a tick
interrupt, and it would be fiddly to try and stop just that interrupt by
itself. It is far simpler to just globally disable interrupts while the
flash is being programmed, and then enable interrupts again when the
programming is complete. That can be done on a flash page by flash page
basis, or if you application can cope with it, on the entire write.
What MCU are you using?
Are you using the fast internal (S)RAM or external SDRAM?
I know that some platforms indeed have problems restoring the context after an interrupt.
The RAM functions are copied to a declared global array that is
of a fixed size. So I don’t think I have some scope problem.
Isn’t the compiler doing all this work for you?
I made a such a routine running from SRAM in one project. But as re-programming the flash is the last thing to do before rebooting, I completely disabled all interrupts during the process.
And as Richard mentioned, you’re not allowed to access some (or all) parts of the flash while re-programming it.
Freescale/NXP K24F with Flash Swap. I am using a function RelocateFunction to write the functions to RAM. I just recently disable interrupts and that doesn’t seem to be helping. I might have a problem not related to FreeRTOS.
I am using taskDISABLE_INTERRUPTS() but I might need to use INT_SYS_DisableIRQGlobal() instead.
I’m using a function from a KSDK 1.3.0 library called RelocateFunction.
I’m okay with disabling all interrupts for the active block that I am in. I understand that I can’t read and write to the same active block. I only need to do that once for some swap indicator. I can write to the inactive portion of the flash while working in the active flash. It’s a feature of this chip, a dual program bank with a swap mechanism. Other than one erase and one write, I will want to flash the other bank while running the current program.
Hi Jason,
I’m afraid I’m not experienced with the part that you are using.
It does not sound like a FreeRTOS problem.
I just read ‘AN4533’: Program Flash Memory Swap, interesting.
Have you tried to run a different function in RAM, a function that does not program the flash and that does take a long time to complete?
When programming the ‘inactive sector’, you say that the part will reset. Does that happen immediately? Have some bytes been programmed successfully? Is there a randomness in when it resets?
One thing that occurs to me and has caught me out in the past - when I’ve had a part resetting - is I’ve forgotten about the watchdog and it’s been kicking in. Is that enabled?
I would like to update you all that the problem wasn’t from FreeRTOS as you all suspected.
I figured I did something wrong but I couldn’t figure it out at the time.
Here is the link just in case anybody else runs into a similar problem. https://community.nxp.com/thread/437197
I didn’t use their SIZE_OPTIMIZATION to define my callback and I didn’t have enough heap space.