1
NXPTM M522XX, KINETIS and i.MX RT / FRDM-KE06Z and uTasker KBOOT questions and observations
« on: May 12, 2018, 06:26:54 PM »
Hello forum,
I am running uTaskerSerialBoot in KBOOT mode on a FRDM-KE06Z and everything is working correctly. I am able to load / reload the test bin on the website and my own KDS processor expert code after modifying the linker addresses to 0x8000. I think that the uTasker implementation of KBOOT does not offer an 'app to boot' entry point like described in the NXP KBOOT manual, so I was thinking about trying to implement one of my own. Looking thru the code, I thought one option could be to create a new entry point function that bypasses fnUserHWInit() altogether (so fnJumpToValidApplication() never gets called) or maybe add some code in the application that sets some reserved area in RAM to a sequence of bytes (lets say 0x12345678), then check for that sequence in addition to the FORCE_BOOT() switch in fnUserHWInit():
My question there is how to create an area in RAM that is guaranteed to be valid for both the app and the bootloader.
Meanwhile, this is a great project. I found some issues on the FRDM-KE06Z page and some changes I made that might make sense for this board that I would like to share.
http://www.utasker.com/kinetis/FRDM-KE06Z.html
It says that J4-15 low with a reset disables the watchdog, but the code has SWITCH_1 set to KE_PORTG_BIT4, which is J5-2. KE_PORTG_BIT3 is the correct port for J4-15. All 3 of these pins require that headers be soldered to the board and jumper wires used though, so I made the change below, which sets the FORCE_BOOT and WATCHDOG_DISABLE to the 2 on-board switches of the FRDM-KE06Z board:
I am running uTaskerSerialBoot in KBOOT mode on a FRDM-KE06Z and everything is working correctly. I am able to load / reload the test bin on the website and my own KDS processor expert code after modifying the linker addresses to 0x8000. I think that the uTasker implementation of KBOOT does not offer an 'app to boot' entry point like described in the NXP KBOOT manual, so I was thinking about trying to implement one of my own. Looking thru the code, I thought one option could be to create a new entry point function that bypasses fnUserHWInit() altogether (so fnJumpToValidApplication() never gets called) or maybe add some code in the application that sets some reserved area in RAM to a sequence of bytes (lets say 0x12345678), then check for that sequence in addition to the FORCE_BOOT() switch in fnUserHWInit():
Code: [Select]
if ((FORCE_BOOT() == 0) && (*ram_from_app != 0x12345678)) {
_DELETE_BOOT_MAILBOX(); // {13}
fnJumpToValidApplication(0); // {25} check for forced boot mode or no application code
}
My question there is how to create an area in RAM that is guaranteed to be valid for both the app and the bootloader.
Meanwhile, this is a great project. I found some issues on the FRDM-KE06Z page and some changes I made that might make sense for this board that I would like to share.
http://www.utasker.com/kinetis/FRDM-KE06Z.html
It says that J4-15 low with a reset disables the watchdog, but the code has SWITCH_1 set to KE_PORTG_BIT4, which is J5-2. KE_PORTG_BIT3 is the correct port for J4-15. All 3 of these pins require that headers be soldered to the board and jumper wires used though, so I made the change below, which sets the FORCE_BOOT and WATCHDOG_DISABLE to the 2 on-board switches of the FRDM-KE06Z board:
Code: [Select]
#define SWITCH_1 (KE_PORTH_BIT4)
#define SWITCH_2 (KE_PORTH_BIT3)