Want to know how to replace string literal in compiled hex file

[robogo]

I am mentoring two college capstone teams on UWB projects using the Qorvo DWM3001CDK boards. These boards have the nRF52833 embedded and use the Nordic BLE stack/

neither team has managed to figure out how to compile the source yet and I want to get them a quick work around while they figure out how to successfully compile the software.

I'd like to know what the encoding scheme is. Whether there is a checksum value embeeded in the hex file that need to be recalulated and changed.

We want to replace the bluetooth device name "DWM3001CDK" to unique names for each UWB board. ie. "DWM3001001"

Thought this would be easy but the string is encode and not human readable.

Also, if anyone one wants to mentor these teams too help them get the source code to compile properly please contact me. 301 916-5722. These are capstone project at Stevens College and NJIT.

DWM3001CDK_full.hex

[hmolesworth]

The Device Name is not in the SoftDevice but typically in the Application, although if only a single hex file is available that will include the SoftDevice. The Device Name usage can be explained by looking here, for example:

ble-advertising-a-beginners-tutorial

If lucky the device name is held in user data in UICR and not in the hex file, similar to (say) a MAC address:

// Some manufacturers define a MAC address within NRF_UICR
// The 6-byte BLE Radio MAC address is stored in the nRF52832 UICR at NRF_UICR_BASE+0x80 LSB first.
// address during programming. Important: if full memory protection is enabled, not allowing the UICR to be read via the SWD interface.
// UICR Register:
// NRF_UICR + 0x80 (0x10001080): MAC_Addr [0] (0xZZ)
// NRF_UICR + 0x81 (0x10001081): MAC_Addr [1] (0xYY)
// NRF_UICR + 0x82 (0x10001082): MAC_Addr [2] (0xXX)
// NRF_UICR + 0x83 (0x10001083): MAC_Addr [3] (0x93)
// NRF_UICR + 0x84 (0x10001084): MAC_Addr [4] (0x54)
// NRF_UICR + 0x85 (0x10001085): MAC_Addr [5] (0x94)

Searching the UICR region might locate the Device Name .. unlikely though.