Entry and Exit of ROM Bootloader, MKE18F + MCUXpresso

[scutumlog_nxp]

Hello,

I'm working on a MKE18F ROM Bootloader project with MCUXpresso IDE. In this project I try to configure the Bootloader in order to update the μC firmware via CANbus.

During my test I solved some issues that have appeared and I updated the firmware successfully through UART and CANbus.

But there are some issues that may cause our system to "lock-up"/brick. To solve this, we need our system to enter the ROM Bootloader when exiting from any reset, and also we want it to exit the Bootloader after a defined timeout. (At the end, we would like to generate a .bin file that contains the Bootloader configuration (BCA); is there any chance to configure the BCA when programming the μC through a debugger that does not require modifying the Linker file?)

But now I am trying to solve some potential problems and... surprise! I discovered that I can't exit the Bootloader using peripheral detection timeout, and also it doesn't entry after reset (Software reset or Reset_b Pin).

I know I can't pretend to use timeout if I entered the Boot ROM with the API tree.

I have tried the next configurations:

1.- Enter at Start-up Process & Timeout exit:

   1.1.- FOPT [7] is set to 1

 "FOPT [7] is set to 1. This forces the ROM to run out of reset:"

//*****************************************************************************
// Flash Configuration block : 16-byte flash configuration field that stores
// default protection settings (loaded on reset) and security information that
// allows the MCU to restrict access to the Flash Memory module.
// Placed at address 0x400 by the linker script.
//*****************************************************************************
__attribute__ ((used,section(".FlashConfig"))) const struct {
 unsigned int word1;
 unsigned int word2;
 unsigned int word3;
 unsigned int word4;
} Flash_Config = {0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFE};‍‍‍‍‍‍‍‍‍‍‍‍‍
//__________________________________________________________^^__
//Byte of FOPT -> FF ->FOPT[BOOTSRC_SEL] set to 1 & FOPT[BOOTPIN_OPT] set to 1‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

These code lines can be found in the startup_mke18f16.c file. 

The information about FOPT register is in these tables (FOPT address and FOPT register) in the KE1xFP100M168SF0RM document:

When I use this configuration, the MCU enters the Bootloader and I can establish communication via CANbus. But if I don't communicate and I let the five seconds pass (default config), it times-out and resets, but it enters the Bootloader over and over instead of jumping to flash user application. We can see the "timeout and reset every 5 seconds" in these oscilloscope captures:

   1.2.- BOOTCFG() pin is asserted

"The pin must be configured as BOOTCFG0 by setting the BOOTPIN_OPT bit of FOPT to 0."

__attribute__ ((used,section(".FlashConfig"))) const struct {
 unsigned int word1;
 unsigned int word2;
 unsigned int word3;
 unsigned int word4;
} Flash_Config = {0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFF7DFE};‍‍‍‍‍‍
//__________________________________________________________^^__
//Byte of FOPT -> 7D ->FOPT[BOOTSRC_SEL] set to 0 & FOPT[BOOTPIN_OPT] set to 0‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The information about BOOTCFG0 configuration is in this table in the KE1xFP100M168SF0RM document:

When I use this configuration, I force the BOOTCFG0 pin to GND then I power-on MCU. The MCU enters the Bootloader successfully but timeout is disabled, after five seconds pass it doesn't timeout. I don't know why this is happening, BCA has the default configuration. But nevertheless when I do a reset through the reset_b pin, it enters the Bootloader again but now, after five seconds, it times-out, resets and jumps into the flash user application (desired behaviour).

We keep in mind the next two flow chars and I think the problem is the two conditional blocks before "Disable Timeout" detection (in Figure 23-2- Kinetis bootloader Start-up Flowchart). We don't know what "Is user application valid?" block is checking.

I have tried these configurations segmenting the flash memory in order to add a manually configured BCA. After setting up the Linker file, the result has been the same. Both projects are attached at the end of the post (Bootloader_KE18f_Projects.zip). 

I hope you can help me, thanks a lot in advance! 

Links:

https://www.nxp.com/docs/en/data-sheet/KL17P64M48SF2.pdf 

https://www.nxp.com/docs/en/data-sheet/KE1xFP100M168SF0.pdf 

Getting Started: ROM Bootloader on the NXP FRDM-KL03Z Board | MCU on Eclipse 

[Alexis_A]

Hi Jan,

Did you try using the Kinetis Flash Tool to modified the BCA register. When you download the MCUBoot package if you follow the next route:

NXP_Kinetis_Bootloader_2_0_0\bin\Tools\KinetisFlashTool\win you can find the .exe of this tool.

If you access the BCA utilites you can configure the binary created in your application. 

In the configuration you can set the timeout you want and the protocol you want to use. With this you don't need to do this manually.

Also I will suggest to check the chapter 2.6 Bootloader entry point. With this you could try to call the bootloader if the software reset flag is active for example.

The user application valid check if there's write something in the offset section of the bootloader otherwise will jump again to the bootloader.

I hope this helps you.

Best Regards,

Alexis Andalon

[scutumlog_nxp]

Hi Alexis,

Thank you for replying.

We already knew about the Kinetis Flash Tool, and this application helped us a lot when we were starting with the bootloader.

As far as entry point with API is OK, we are using it correctly. 

Could you go in depth what you are referring to when you talk about the offset section of the bootloader? (quoted below)

"The user application valid check if there's write something in the offset section of the bootloader otherwise will jump again to the bootloader."

How do we configure and which are the registers needed in order to entry the bootloader after any reset?

Thanks a lot! :smileyhappy:

Jan.

[Alexis_A]

Sorry Jan, with that comment I was refering to the the bootloader located in flash, in case you have this kind of bootloader it always going to enter after any reset but in this case is located in ROM.

I think the best approach to do this will be call the bootloader in the Reset ISR Vector depending of the reset source. In the chapter 2.6 of the MCUBoot Refence Manual there's an example of how to call the bootloader.

I hope this helps you.

Best Regards,

Alexis Andalon

[scutumlog_nxp]

Hi Alexis, 

Thank you for the fast reply!

In our case we can not use the solution that you propose, because as it seems the bootloader called from API doesn't have enable timeout detection. Is this correct? 

Source by Erich Styger: https://community.nxp.com/thread/456739#comment-928098 

So, is there any errata in Kinetis ROM Bootloader (Chapter 23) section from KE1xFP100M168SF0RM document or in the datasheet?

When we enter into the bootloader with FOTP[BOOTSRC_SEL]== 11, it doesn't exit with the timeout detection. Could the issue be related with "Is user valid application?" block (1)?

If we enter the bootloader with the API (2.6 Bootloader entry point) and then do a reset pulling the Reset_b pin to GND, only then, it enters the bootloader and then exits with the timeout successfully and returns to the user application. Maybe this means that the user application is valid?

Thank you Alexis! :smileyhappy:

Jan.

[Alexis_A]

Dear Jan,

Looks like the Bootloader its exiting the application the application but after some miliseconds in the application the MCU reset by the watchdog. You could check this if you print something after enter you're application. 

There's a note in the reference manual of the KE1xF that explains that if you want the Watchdog to support the bootloader is necessary to reconfigure the bootloader because unless in the start up code the watchdog is being disabled this will be ignored unless you reconfigured. Check the chapter 30.4.3.2 Reconfiguring the Watchdog for more information.

Let me know if this helps you.

Best Regards,

Alexis Andalon

[scutumlog_nxp · Accepted solution]

Hi Alexis! :smileygrin: 

We worked in it and seems that the problem is due to the watchdog! We could find the problem by making a GPIO toggle inside a while, and the toggling only lasted around 8ms, this showed us that the user application started running indeed.

We have been trying to set Watchdog CS[UPDATE] to 1, but the problem remains. Anyway we kept trying and finally we managed to disable the Watchdog successfully using these API functions:

WDOG32_Disable(WDOG);‍
WDOG32_Deinit(WDOG);‍‍

Thank you so much! this was driving us crazy.

[Alexis_A]

Dear Jan,

I'm glad that this information help you.

Best Regards,

Alexis Andalon