I would like to write my own bootloader code and also make use of a sector of program flash to store calibration and setup parameters, and give my operating code the ability to update params in flash as required. However, I am worried about restrictions on code running from program flash being responsible for modifying program flash. I recently wrote code to do these things for the 56F8255, and it has the option to freeze code execution (basically a single-instruction infinite loop waiting for status bit to change, i.e. no need for pgm mem access while it waits) while the flash is busy so code execution can co-exist with flash programming in the same flash module. I don't see the same for the 56F83XXX... so... how should I handle this? Does the code issuing instructions to the FTFE module have to reside outside of the block where I want to burn things from my code, be it either a custom bootloader or code modifying parameters in a flash sector I reserve for setup data? If so that could make life challenging if I want to make full use of both flash blocks.
I like the idea of implementing functions built in to the flash driver API. The 56F83XXXRM document makes reference to Bootloader Reference Manual for more details on each API command, and to integrate the flash driver APIs (ref. section 6.8.5) that I need to "add flash driver related files (rom_api.h, rom_flash_api.h,m fom_flash_api.c, etc.) to the project. Where can I find the Bootloader Reference Manual and the "flash driver related files?"
As you know that the MC56F83xxx supports SDK package, pls download the SDK package from the link:
After you create a new project, you can see the file fsl_flashiap.c
Hope it can help you
Thanks for that. If I'm understanding correctly, does this mean that I can erase and program sectors anywhere (subject to care re linker command file / memory map) in flash with code running elsewhere in flash, even from the same flash block, so long as the API is used because actual invoking of FTFE command happens from code in boot ROM where the API functions reside, not flash block0 or block 1? IOW, using the API means I can avoid flash memory contention problems during execution of FTFE commands?
Assume that your code is saved and executed in block0, interrupt vector table is saved in block0, if you erase/program block1, there is not any problem, you can run your code, execute ISR in block0.
Assume that your code is saved and executed in block0, interrupt vector table is saved in block0, if you erase/program block0(the empty sector), I have to say there is problem exactly if you run code or execute ISR, because you run in the same block no matter whether you execute code to operate in ROM or RAM.
In conclusion, when one block is erased/programmed, you can not access it for example fetching code or reading data.
Hope it can help you
As you know that the MC56F83xxx has TWO independent flash block, while the MC56F8355 has only ONE flash block. The MC56F83xxx has ROM flash bootloader and ROM flash driver, you can call the ROM flash driver to operate Flash like erasing/programming operation. Regarding the erasing/programming the same flash block where the code is saved in and executed from, pls refer to comment in flash driver for MC56F83xxx:
* MC56F83xxx has two flash blocks, it support read/execute code on one flash block while erase/program on another flash
* block. Make sure don't access the flash block while it performs erase/program operation.
* If put the code(including ISR) only in one flash block, and erase/program another flash block, then it is OK to
* enable the interrupt since there is no access(even the ISR) to the flash block which is performing erase/program
* If move the vector table, ISR code to RAM(mapping to flash space), then it is also OK to enable the interrupt, since
* there is no access(even the ISR) to the flash block which is performing erase/program operation.
* Anyway for safety reason, it is highly recommended to disable the interrupt before ROM flash API call.
Hope it can help you