I’m troubleshooting an issue related to DFU failures using the mcuboot bootloader, and I wanted to ask a clarifying question:
When I follow the steps outline here to build the project and use the Notecard CLI to create a binpack file, does that resulting file include the bootloader itself?
Is the bootloader on the host replaced during outboard DFU?
Right now, when I build my project, Nordic’s SDK produces a merged image with both the bootloader and the app. This image has mcuboot starting at 0x00, and the application is at 0xc200. So when I tell the Notecard CLI to prepare a binpack, would I want to tell it 0x00 (which is where the bootloader begins) or 0xc200 (which is where the actual app begins)?
Troubleshooting issues has shined a spotlight on some gaps in my understanding of the details of what’s going on during outboard DFU.
Sorry for the delay on responding here! If your intent is to update only the application , you’d package the binary at the application’s install address (in your case, 0xc200 ). If your intent is to update a merged image that includes MCUboot + app , you’d be telling binpack to install that merged binary at 0x00 (because that’s where it begins).
Thanks Rob. This is with the Adafruit Feather nRF52840 Express, so the host MCU is the nRF52840.
So, it sounds like you’re saying that the outboard DFU process CAN replace the bootloader, having the bootloader flash over itself, if I give it 0x00 start address and a bin file that includes the bootloader. In other words, it can do either or both, depending on the address and bin that I provide. If I’ve understood correctly, this is good news and helps rule out one possible cause. Thank you!
I’ve been struggling with an issue where the bin files coming out of the Nordic SDK are not considered bootable or valid by MCUBoot, but I think this issue must be unrelated to the Notecard or its associated tools, based on troubleshooting I’ve been doing.