• State Verified Answer
  • Replies 5 replies
  • Subscribers 65 subscribers
  • Views 167 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 325888
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Merged binary (.bin) of SoftDevice + application bricking devices, differs from the merged hex when flashed?

rbmarcus

I'm attempting to generate a binary blob containing both the S140 SoftDevice (to be placed at address 0x1000 in flash) and the main application firmware (at 0x26000).

I use the following command to generate a merged hex: mergehex --merge ./main_app.hex ./s140.hex -o ./mergedapp.hex. This merged hex is flashed using JLinkExe or nrfjprog and the code executes as expected.

I use this command to generate a binary: arm-none-eabi-objcopy -I ihex -O binary ./mergedapp.hex ./mergedapp.bin, and then I flash it to my nRF52840 MCU using JLink Commander: loadbin mergedapp.bin 0x1000. This method doesn't seem to work, despite flashing the two binaries separately (at 0x1000 for the s140.bin and 0x26000 for the main_app.bin) and flashing the merged hex having worked properly. Using memrd, I noticed some key locations in flash such as 0x1000, 0x26000, etc differ when I flash the merged binary compared to the merged hex. 

I've also tried to pad the SoftDevice before merging by using --pad-to=0x26000 --gap-fill=0xFF, but the end result is still a nonfunctional program.

I've included some photos below of the device memory layout read using the Programmer tool. The first photo is from flashing the SoftDevice and application separately or flashing the merged hex (everything looks normal), and the second photo is from flashing the merged binary.

Parents Reply Children
  • 0 in reply to Nguyen Hoan Hoang

    To my knowledge this is incorrect. I have a MBR at 0x0, and it cannot be placed elsewhere. This is a mature project that has always had its SoftDevice placed at 0x1000. 

    Most of the information I’ve provided in the original post outlines what I tried that has and hasn’t worked. I do have a working solution for my use case (concatenating the binaries over CLI and piping the output into a separate file), but I’d like to figure out why a merged hex converted to a binary produces a different outcome than converting both individual hex files into binaries and flashing them separately. 

  • +1 in reply to rbmarcus

    Now I think I get it. The thing is that Softdevice hex also has MBR at 0 inside.  When you merge the hex, it will automatically override your MBR at 0.  So everything is back to normal location. 

  • 0 in reply to Nguyen Hoan Hoang

    Directly flashing the SoftDevice works, regardless of whether I flash it as a hex or as a binary at address 0x1000. If the MBR is contained within the SoftDevice hex, I would expect a duplicate MBR in flash to cause issues since it would shift the remaining SoftDevice data to different addresses, but that doesn’t seem to be the case here.

    Maybe it’s redundant by design to prevent user error? My assumption was that the MBR is a separate blob flashed alongside the SoftDevice, and the process is abstracted away when using SES or similar. I opt for CLI-based building and flashing whenever possible so I have no basis for this assumption, but over CLI I flash the MBR and SoftDevice separately with no problems so far.  

  • 0 in reply to rbmarcus

    Hi,

      is correct. The All SoftDevice .hex file we distribute includes the MBR and must be flashed at address 0 (the MBR is also available as a separate .hex for projects that does not use the SoftDevice, but that is a different matter).

Related