MCUBootloader porting to MKL17Z128VFM

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCUBootloader porting to MKL17Z128VFM

Jump to solution
785 Views
Alexander_S
Contributor II

Dear community,

On my endeavor to port the MCU Bootloader to the MKL17Z128 I came to a point, where I consider the instructions in the reference manual (MCU Bootloader v2.5.0 Reference Manual) a bit imprecise up to the point, where I'm lost. It might be just me and my lack of understanding. I have, as a starting point, the following packages and SDKs (and MCUXpresso):

1) MCUBOOT_2.7_FRDM_KW36, the bootloader source tree

2) SDK_2.5.2_MKE16Z64xxx4, a SDK for the MKE16Z64 with the bootloader middle ware

3) SDK_2.8.0_MKL17Z128xxx4, the SDK for my target processor

I understand that I have to take the sources from 1) plus something from 2) plus the device specific files and drivers from 3) to form a compilable project with the bootloader as middleware.

It's just, that I do now know where the project for MCUXpresso should come from and, in the reference manual, which of the above mentioned parts play which role. Chapter 10, bootloader porting, is a bit unclear or unprecise in that area.

Btw., this is not my first project as an embedded engineer and I was easily able to create, compile and download a project in MCUXpresso starting with the SDK in 3) above.

Could anyone point out how those things should be assembled (pun intended) together to get a project that generates the bootloader?

Thanks for your time!

Kind regards,

Alexander

0 Kudos
1 Solution
755 Views
mjbcswitzerland
Specialist V

Hi Alexander

There is a MODBUS slave loader for the KL17 in the uTasker project - it has been used in a number of industrial products during about 10 years so it immediately available and proven reliable.

It supports Modbus ASCII and RTU (with or without RS485 control) on all KL17 UARTs and can operate as master too if needed. The exact solution is not described in the uTasker Serial Loader guide but out-of-the-box it works like this:
- The slave has a block of 65 holding registers; the 65th holds the present loader state.
- The master writes a block of new firmware as a single write to the first 64 holding registers, after which the content is programmed (on first write the application area of flash is erased too).
- The master repeats writing 64 register blocks to write the rest of the new code in a linear fashion.
- When the master has transferred all the code it sends the last block as a non-64 register block, which is written and understood to signify the end of the firmware upload file. If the firmware length happens to divisible by 64 it sends a further dummy holding register write to the start of the 64 register address with zero data to close.
When the transfer has completed the new firmware is started automatically.

Other strategies or master fetching is possible by modifying the Modbus application layer - I have attached the Modbus slave loading method so you can see it is simple to understand and further customise if needed.

The exact size of the Modbus loader for KL17 (out-of-the-box method) is 10.3k Flash, when built with GCC and thus the application can start at 0x2c00 and uploads of up to 117k programs are possible.

It is also possible to send AES256 encrypted firmware over the Modbus link if the KL17 is secured and you need to distribute IP protected code to the field. Additional code size cost = +5k Flash. The uTasker package contains utilities to do all code encryption too.

In case you don't have Modbus operation in your application the uTasker Modbus package is an immediate proven solution for your device.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training or product development requirements

 

View solution in original post

3 Replies
778 Views
mjbcswitzerland
Specialist V

Hi Alexander

You don't need to port anything to the KL17 - it already has this boot loader in its ROM. Just hold down the BOOT pin at reset to use it.

If you need more flexible boot loading (other protocols, SD card etc.) it is also available as out-of-the-box solution for the KL17 in the uTasker project.
- User's guide https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf

Regards

Mark
uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training or product development requirements

 

767 Views
Alexander_S
Contributor II

Hello Mark,

That's right and I know about the ROM bootloader, but we need a proprietary one running Modbus via UART for the SW-download and control commands. I'll look if uTasker would be an alternative. Thanks for the hint!

Kind regards,

Alexander

0 Kudos
756 Views
mjbcswitzerland
Specialist V

Hi Alexander

There is a MODBUS slave loader for the KL17 in the uTasker project - it has been used in a number of industrial products during about 10 years so it immediately available and proven reliable.

It supports Modbus ASCII and RTU (with or without RS485 control) on all KL17 UARTs and can operate as master too if needed. The exact solution is not described in the uTasker Serial Loader guide but out-of-the-box it works like this:
- The slave has a block of 65 holding registers; the 65th holds the present loader state.
- The master writes a block of new firmware as a single write to the first 64 holding registers, after which the content is programmed (on first write the application area of flash is erased too).
- The master repeats writing 64 register blocks to write the rest of the new code in a linear fashion.
- When the master has transferred all the code it sends the last block as a non-64 register block, which is written and understood to signify the end of the firmware upload file. If the firmware length happens to divisible by 64 it sends a further dummy holding register write to the start of the 64 register address with zero data to close.
When the transfer has completed the new firmware is started automatically.

Other strategies or master fetching is possible by modifying the Modbus application layer - I have attached the Modbus slave loading method so you can see it is simple to understand and further customise if needed.

The exact size of the Modbus loader for KL17 (out-of-the-box method) is 10.3k Flash, when built with GCC and thus the application can start at 0x2c00 and uploads of up to 117k programs are possible.

It is also possible to send AES256 encrypted firmware over the Modbus link if the KL17 is secured and you need to distribute IP protected code to the field. Additional code size cost = +5k Flash. The uTasker package contains utilities to do all code encryption too.

In case you don't have Modbus operation in your application the uTasker Modbus package is an immediate proven solution for your device.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training or product development requirements