Why is the soft device provided as a hex file and not object code?

[DiBosco]

Folks,

We're wondering how the soft device can work with it being provided as a hex file? Usually with things like this you'd get object code to link to, but that doesn't seem to be the case.

A colleague here reckons he's found source code for an LE stack in the SDK, but that's not the case is it? Have we misunderstood how  this works?

I have got a program running with custom characteristics from the template project and it works a treat, but it would be good to know how this set up works.

Many thanks.

[wpaul]

DiBosco said:

A colleague here reckons he's found source code for an LE stack in the SDK, but that's not the case is it?

The Nordic SoftDevice source is not public. Your colleague may have found the source code for _a_ BLE stack, but not the Nordic one.

Strictly speaking, you don't "link to" the SoftDevice. APIs are implemented as system calls using the ARM SVC instruction. The choice was made to allow the SoftDevice to directly intercept all CPU interrupts and pass through the ones it doesn't care about to user application code, as opposed to doing it the other way around. This was likely done to minimize the latency in handling radio interrupts. To call an API in the SoftDevice, the application issues an SVC instruction, which then causes the CPU to enter the SoftDevice's SVCall trap handler.

Since you don't make direct function calls, the SoftDevice can be just a flat binary file with no symbol table.

That said, I found Nordic's "flash the MBR, SoftDevice and application separately" design to be inconvenient. I wanted to be be able to compile a single image and flash everything in one step. To that end, I wrote a small script that uses objcopy to convert the .hex file in to a libsoftdevice.a file for easy linking with my application. You can find it here:

https://github.com/netik/dc27_badge/blob/master/software/firmware/SoftDevice_S140/mkelf.sh

The resulting ELF object just has a binary blob in it with a couple of symbols added.

Note: in order to get the right start address value in the ELF header of the firmware image (which is useful when you run the firmware from the debugger), you need to hexdump the first few bytes of the SoftDevice blob in order to see the reset vector address. This address can vary depending on the SoftDevice build. If you know what the ARM Cortex-M4 vector table looks like, the address is easy to find. The script assigns this address to a symbol called "softdeviceEntry" which is used in the project linker script as the image entry point using the ENTRY() macro.

-Bill

[haakonsh]

Seperating the SoftDevice + MBR into a seperate hex file makes it easier to do BLE DFUs with minimal flash usage. We can run a DFU on the SoftDevice + MBR first, then update the application afterwords. 

@DiBosco: See Application programming interface.

[DiBosco]

Thank you both of you, most helpful.