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

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

rbmarcus — Mon, 06 May 2024 23:29:29 GMT

This turned out to be what was going wrong. Thank you Einar Thorsrud and Nguyen Hoan Hoang for responding and pointing out the problem, and I apologize for my initial skepticism. It's on me for trusting the build process I was given instead of doing my own research to confirm. I'm still not sure why the binary works, but since it doesn't match the size of a binary created from the stock hex, maybe the previous devs removed the MBR from it? I can share our internal version of the S140 6.0.0 SoftDevice if anyone is interested, but aside from that everything is clear going forward.

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

Einar Thorsrud — Thu, 25 Apr 2024 07:10:58 GMT

Hi,

Nguyen Hoan Hoang 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).

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

rbmarcus — Thu, 25 Apr 2024 03:56:28 GMT

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.

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

Nguyen Hoan Hoang — Thu, 25 Apr 2024 02:29:51 GMT

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.

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

rbmarcus — Thu, 25 Apr 2024 02:23:32 GMT

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.

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

Nguyen Hoan Hoang — Thu, 25 Apr 2024 01:44:00 GMT

What worked and what didn't work exactly ? Softdevice has to be flashed at 0 not 0x1000. Why Softdevice to be placed at 0x1000?