For a project I'm planning to add a 32k bootloader to our 256k RA2L1 to provide the functionality of in-field software updates. When I read the user manual, it states: "The MCU supports programming of the flash memory by the user program. The programming commands can be used with user programs for writing to the code and data flash memory. This enables updates to the user programs and overwriting of constant data fields."
Afterwards, there's the following diagram:
The diagram states that the Code flash memory can only be programmed and erased when the User program is ran in internal SRAM. However I'm not certain wether this is ALWAYS the case, or just when making use of "background operation facility".
In short my question is: Can I program/erase code flash memory, from a user program running in code flash memory when not making use of background operation?
You just have to declare some variable as no_init and write there your command. I reccomend you that this command is something a bit complicated to get randomly. For example four bytes not containing 0x00…
Yes, you cannot program code flash by code running from code flash on the RA2l1, only from code running from a location not in code flash (i.e. SRAM).
Background operation only applies to the programming…
Background operation on the RA2L1 allows the data flash to be programmed by code running from code flash :-
to program the code flash, the code has to be running from internal SRAM
Is this the same when not using the background operation though? Or am I understanding this funtionality wrongly
Background operation only applies to the programming of dataflash. If you are programming code flash, background operation isn't possible :-
I see, so the only possibility for a bootloader on this chip is to make sure it fits in SRAM, thanks for your help.
The Bootloader can reside in flash, it is just the Code flash programming routines that have to run from RAM as it is not possible to read data from the code flash (i.e. read instructions that the CPU will execute) when the code flash is being erased or programmed, this does also mean interrupt handler routines that are in code flash cannot be used when programming or erasing the code flash, and the interrupt vector table cannot be read if it is located in code flash when programming or erasing the code flash.
Thanks again for replying Jeremy. We now have a clear idea of how we want to implement a bootloader into the product.
Ideally we would want to be able to trigger the bootloader routine by writing a certain command to our SRAM and then trigger a reset. On startup the device would check if this command is present, if not, the application will simply start, if it is present, the bootloader routine will be started.
Do you know if it is possible to write a certain area of "no-init" SRAM which is retained on a warm reset, so that we can realize this bootloading routine?
You just have to declare some variable as no_init and write there your command. I reccomend you that this command is something a bit complicated to get randomly. For example four bytes not containing 0x00 nor 0xFF. I've been using this approach to communicate my main programs with the bootloader with good results since 2010.
Hi Jeremy, just a short follow-up question.
You mention that interrupt handler routines that are in code flash cannot be used when programming or erasing the code flash. Does this mean that interrupts need to be disabled before starting the programming routine? Or that the interrupts simply will not be handled when this routine is in process.
An example; The bootloader is programming the code flash with a firmware update, however while this is happening, the Watchdog Timer peripheral generates an interrupt.
What would happen in this scenario?
Thank you for your answer!
If an interrupt occurs during Code flash programming or erasing, and the Vector Table is located in Code Flash (as set by the VTOR register), then the CPU will not be able to read the Interrupt Vector information correctly, and will start exectuting the interrutp handling routine at some random address, and will eventually end up generating a fault condition.
So interrupts either need to be disabled during flash programming, or, interrupt handling needs to be relocated elsewhere, this means the vector table, the interrupt handler and any functions the interrupt handler uses (e.g. FSP or C runtime library), cannot be located in the flash that is being erased or programmed.