I'm using MCUXPresso IDE + custom board with a MK10 kinetis microprocessor and a J-Link Ultra programmer. This works great in general but I'm trying a slightly more complicated set up and have run into a problem.
I've added a custom bootloader to my processor which boots the app firmware. The app firmware has a 256 byte header including the length and CRC of the firmware. This header is at 0x1_0000 and the actual firmware starts at 0x1_0100 (AKA immediately after the header).
If I do a debug launch as normal the tools program the built .axf which does not include this custom header, and therefore the bootloader sees the app firmware as invalid and overwrites it / refuses to boot.
If I take the .axf convert it to a .bin and use a helper script to append this header, I can then program it manually using JLink command:
connect
... options ....
loadbin path/to/modified_app.bin 10000
r
g
Which works perfectly.
------------------------------------------------------------------------------
BOOT
Version 0.0.1 Debug (Feb 11 2021, 19:58:19)
------------------------------------------------------------------------------
Verifying FW banks
state: OK, crc: A9019607
Current: Pass (0.0.3 Release, Feb 11 2021, 20:43:38)
...
Booting main application (0x 103F9)...
------------------------------------------------------------------------------
APP
Version 0.0.3 Release (Feb 11 2021, 20:43:38)
------------------------------------------------------------------------------
I would like to be able to do the same via the debug launch so I can program and debug my code directly via MCUXpresso IDE. Unfortunately I haven't managed to find any docs that explain how to use each of the options, and have no success with my initial attempts.
On the startup tab (of the debug launch) I can change it to load the image via a file, which I can set to my .bin and specify the offset (0x10000). However that doesn't seem to work, the previous firmware boots, and diffing a dump of the flash shows no changes.
Another option I've found is to disable the "load image" checkbox and instead add the following to the initialization commands:
monitor reset
monitor loadbin "path/to/modified_app.bin 0x10000"
This works occasionally (three out of about 10 attempts). When it works I see the processor reset and the bootloader loads the new app (but interesting enough it doesn't seem to hit the auto inserted breakpoint). The rest of the time the processor doesn't even reset, which is interesting because that monitor reset should cause a reset even if the loadbin failed.
A third option is to add the following to the run commands:
monitor reset
monitor loadbin "C:\Users\andrewp\Documents\code\magpie\firmware\repeat\repeat_app\Debug\app_part.bin" 0x10000
monitor reset
This actually seems to work (and stops at the breakpoint).
So great I have something that works, but I'd like some more information on how all these options work and fit together, are there any docs that indicate what order everything is run in, and what command each checkbox option inserts an d where? Also why is the load file with my custom .bin is not working.?
Thanks for any advice,
Andrew
