Writing to UICR + software reset

[Nicholas_Nuti]

Hello,

I have a simple question. So, I'm trying to write some manufacturing information into the UICR but once I write to these addresses I can't see the device via bluetooth unless I do a hard reset. I tried using: NVIC_SystemReset(); but I was unsuccessful. Is there a way to do a soft reset so that I may see the device via a bluetooth scan without having to do a hard reset after writing to the UICR?

I need this functionality because in the future I plan on implementing DFU so that permanently enclosed devices may get updated firmware via bluetooth. When the firmware changes, the information in the UICR will change and I will have no way of hard resetting these enclosed devices. I.E. these enclosed devices become useless if I change the UICR information in the current case.

Thank you,

Nick

[hmolesworth]

This might not answer your question directly, but it is information worth knowing when writing to the UICR; the reason is that the BLE MAC address for some BLE modules is contained in the UICR instead of being generated from the 64-bit unique ID (as in the Nordic examples). I made these notes:

/**@note
 * Rigado has defined a MAC address stored within NRF_UICR, which matches the
 * address inscribed on the module. The Nordic examples (eg uart and most others)
 * use the Device Id in NRF_FICR to form a MAC address, which is different and fixed
 * The 6-byte BLE Radio MAC address is stored in the nRF52832 UICR at
 * NRF_UICR_BASE+0x80 LSB first. Modules with factory firmware AA and AB are provided
 * with full memory protection enabled, not allowing the UICR to be read via the SWD interface. If
 * performing a full-erase, the MAC can then only be recovered from the 2D barcode and human-readable text.
 * Modules with factory firmware code AC and later no longer enable read-back
 * protection from the factory, allowing the MAC address to be read with an SWD programmer.
 * UICR Register (94:54:93:XX:YY:ZZ) see BMD-350 Data Sheet v2.0:
 * 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)
 *
 * Nordiv MAC Address - from 64-bit unique id in NRF_FICR->DEVICEADDR
 * ==================
 * DA:88:19:2D:84:27 from DE5FDA88192D8427
 *
 * Last 2 bits in 48-bit stream - top 2 bits in last byte of Device Address
 * 00 Public
 * 01 Static
 * 10 Resolvable
 * 11 Non-Resolvable
 *
 * Note that even though the address is "Random", it is invariant and never changes
 * for a specific Nordic device as the NRF_FICR->DEVICEADDR registers are Read-Only
 */

It is possible the code was using the UICR MAC address which disappears when overwritten and reset, maybe causes loss of communication on that MAC. If the host isn't expecting that specific MAC address the this of course does not apply,

[Nicholas_Nuti]

Thank you for that information! It is helpful to know that the MAC address can be defined in two different ways. Although this could be important, I'm fairly sure that my MAC address is being stored in the FICR. Maybe I should try writing my UICR data to a different area. I will see what I can do. Thank you hmolesworth for your response!