Can there be a 2018 refresh for Bootloader package?

[donwilley]

I am working on a port of the bootloader to an unsupported device (MKL16Z4), but the present 2.3 SDKs have different interfaces and some odd results are coming up. 

I think I need some of the drivers from the current SDK for my target, but the bootloader projects seems to use virtual paths for some files, and but for others that seem like they should, don't.  When fixed to use virtual paths, unhappy errors occur.

Advise welcome.

[jingpan]

Hi,

In Kinetis bootloader2.0.0 package, there is a rm "Kinetis Bootloader v2.0.0 Reference Manual.pdf". Chapter 10 of the rm shows how to port the bootloader to an unsupported kinetis bootloader.

Regards,

Jing

[donwilley]

Thanks for the response.

Chapter 10 is great, as far as it goes.

I am looking for something a little different.

For me, problems arise wanting to use device specific drivers from 2.3 (March 2018) vs. older 2.0 versions (Mar/April 2016) from the bootloader release.

I can understand that it would probably take a lot of resources to revise bootloader each time the SDKs are revised, but two years seems like big difference.

I am mostly interested in resolving problems with uart0, so my examples below weight heavily in that area.

My applications use UART0 without problems, but my ported build of bootloader, fail UART0 transmit the way previously reported here: https://community.nxp.com/message/1007277

My thought was that if I use latest UART0 code from the SDK specific to my MCU, my chances of success would increase.

Here is a partial directory of some drivers from the bootloader 2.0 ./src/drivers directory.

It is hosted on a Window 10 system, but I like bash and the detail shown by ls -lat.

/c/nxp/bootloader/src/drivers (master)

$ ls -lat /

-rw-rr 1 30630 Mar 29 2016 uart/fsl_uart.h

-rw-rr 1 32648 Mar 29 2016 uart/fsl_uart.c

-rw-rr 1 13672 Mar 29 2016 port/fsl_port.h

-rw-rr 1 34827 Mar 29 2016 lpuart/fsl_lpuart.c

-rw-rr 1 31613 Mar 29 2016 lpuart/fsl_lpuart.h

-rw-rr 1 100199 Apr 13 2016 flash/fsl_flash.c

-rw-rr 1 58230 Mar 24 2016 flash/fsl_flash.h

Vs

/c/nxp/SDK_2.2_MKL16Z128xxx4/devices/MKL16Z4/drivers

$ ls -lat

-rw-rr 1 39520 Mar 1 10:55 fsl_uart.c

-rw-rr 1 30470 Mar 1 10:55 fsl_lpsci.h

-rw-rr 1 35611 Mar 1 10:55 fsl_lpsci.c

-rw-rr 1 32414 Mar 1 10:55 fsl_uart.h

-rw-rr 1 130244 Nov 23 04:55 fsl_flash.c

-rw-rr 1 65999 Nov 23 04:55 fsl_flash.h

Comparing these files generally shows a lot of small cosmetic differences.

However some changes or functions added/removed can make compatibility problems.

Porting the bootloader seems to depend on making the right choices.

Chapter 10 and other parts of the documentation warn about this.

It could be more generous with rationale behind choices.

Shown above, lpuart.c is not in device specific SDK because the MKL16Z doesn’t support it.

It was confusing when I found that instead of uart.c, the MKL25Z4 I started from used lpsci.c, which seemed like it might also be lpuart like.

When I learned that the only config to use the uart0_peripheral_interface was the MKL25Z4, I wanted to investigate if it might be possible to use the most frequently used config.

My investigation seems to be pointing to a lack of symmetry between UART0 vs. UART1 & UART2, so even though uart.c and lpsci.c are both available lpsci.c seems to be the right choice.