Need help to develop a custom flash bootloader for firmware updating KL27Z

[danieltruong]

Hi fellow community members,

I'm wondering if anybody can give me some advice how to start developing a custom bootloader in flash for the Kinetis MKL27Z256? I'm using this MCU to connect with a BLE module through a UART channel (LPUART0) and would like to leverage this communication channel to a remote host to update the firmware through Bluetooth, i.e. OTA.  Once the BLE module initialization is done and the connection is established, we will use our own protocol between remote host and the resident MCU to exchange data and re-program the flash during the firmware update.

I read through many documentation and app notes related to KBOOT but the information are pretty much scattered and I still don't know for sure how to execute this project using Kinetis Design Studio. 

Here are what I know (please correct if I'm wrong at any point):

1. I have to set the FTFA_FOPT register so that the MCU will boot from flash, not from ROM. Normally I can do this by editing the file "startup_MKL27Z4.S" in the KDS tool (under Flash Configuration area, set byte address 0x40D to 0x3F)

2. I have to write my custom bootloader, which looks something like this:

   a. read some push button, if pressed, continue the firmware update process. If not pressed, go to user application (normal mode)

   b. initialize (some I/O pins, clocks, LPUART0 - which is the channel that connects to the BLE module)

   c. issue some commands to initialize the BLE module and finally starts advertising.

   d. when connected to the host, start the dialog and exchange data (in chunks) to get new firmware image and update the flash in user application area

   e. when finished, jump to user application code.

My questions are as follows:

1. How do I integrate my "custom bootloader code" above into the normal "user application code" in KDS?

2. Is the entry point of the bootloader fixed at any location in flash area ? Or user programmable ?

3. Is there a need to call bootloader routine in user application (similar to ROM bootloader call provided in some example) ? Or MCU jumps to bootloader automatically upon boot (with FTFA_FOPT=0x3F)?

4. How do I set up the starting address of the user application code in KDS?

Your help would be greatly appreciated.

Daniel

[jorge_a_vazquez]

Hi Daniel Truong 

I would recommend using MCUBOOT (KBOOT) as long as the KL27 already have a ROM bootloader, but one important part to consider is that the BLE module would have to send the specific commands of the MCUBOOT protocol. Now if you have the need to create your own bootloader then there shouldn't be any problem.

Regarding your statements:

1. Yes, by default all the IDE sets the FOPT area to boot from flash, so there shouldn't be any problem here.

2. Yes, this is how a bootloader mostly looks, one important point to consider is that in the step "d", you have to update the flash with a code running in RAM, as long as you cannot write into de Flash when the code is running in a flash.

Now, regarding your questions:

1. How do I integrate my "custom bootloader code" above into the normal "user application code" in KDS?

I would highly recommend you MCUXpresso IDE, this is the last IDE with fully support from NXP. Also with this IDE you have the "memory management tool" which helps to manage the linker and you can use this tool to reserve memory for your bootloader.

In a final application you normally locate the bootloader in the address 0x0 of the memory flash, so the first entry point is the bootloader, and so, you can define in your bootloader if run the state machine of the bootloader or jump to application.

So, for example, your bootloader would be located in 0x0-0xBFFF and the start of your application would be in 0xA000-0x36000.

2. Is the entry point of the bootloader fixed at any location in flash area ? Or user programmable?

As I mentioned, normally a bootloader is located in the 0x0 in order to be the first to be executed, but you can be located wherever your needs.

3. Is there a need to call bootloader routine in user application (similar to ROM bootloader call provided in some example) ? Or MCU jumps to bootloader automatically upon boot (with FTFA_FOPT=0x3F)?

In the case of FOPT, it will jump to the ROM in the boot sequence, so it does not need to call it within your code. Again, you can configure this as your needs, for example, if your user code needs to call the bootloader, you can do it.

4. How do I set up the starting address of the user application code in KDS?

In any ARM Cortex M0, the firsts 8 bytes of the flash includes the PC and SP, so at the reset sequence, it will load the PC with the address of your application (or your bootloader). This is also configurable, and it doesn't depend on the IDE, so I would recommend MCUXpresso.

The flashloader example is not included in the SDK package because the MKL27Z already has a ROM bootloader.

Hope this information could help you, please don't hesitate to contact me if you have any other question about this.

Regards

Jorge Alcala

[danieltruong]

Hi Jorge,

Thank you so much for your reply. You answered most of my questions. 

I’d like to ask a few specific details on question #1:

1. You mentioned “..your bootloader would be located in 0x0-0xBFFF and the start of your application would be in 0xA000-0x36000..”. Let’s say I like to choose that same range. How do I set up this memory arrangement in MCUXpresso ?
2. Assuming my bootloader code is the file named “myBootloader.c”, where do I place this file in the system of file hierarchy within MCUXpresso (e.g. >source)? How does the linker know that the file is the bootloader so that it will place the associated binary file at its entry point in the flash?
3. It makes sense that, as you mentioned, I have to move the bootloader to RAM area before updating the flash with new image. How do I perform that moving task? Do you have a code example? If not, can you outline briefly the strategy at a high level?  
4. Is there any protection scheme we should employ in case the process of updating flash is interrupted and aborted in the middle (e.g. loss of power) and we don’t find ourselves getting hosed due to the corrupted (bootloader) flash?

Thanks,

Daniel