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,

[Einar Thorsrud]

Hi Nick,

In general, there is no problem writing to UICR and performing a soft reset. You can see an example of that in gpio_output_voltage_setup() in <SDK16>\components\boards\boards.c, so I suspect hmolesworth is onto something. Which UICR address(es) do you write to, and what is these address(es) used for?

Einar

[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!

[Nicholas_Nuti]

Hi Einar,

Thank you for that reference in boards.c it is helpful!

I think I found the problem, at least, in this case. It seems as though, I can't see the device after programming it with a hex file via command line tools unless I invoke the following:

nrfjprog -f nrf52 --reset (which is technically a hard reset)

So technically it wasn't the UICR causing me to not be able to see the device... it was that I needed to hard reset the device after programming it with a hex file.

This is odd to me. Does the UICR not need a soft reset after writing to it? Typically when I write to it using the command line tools, I need to initiate a reset so that the device will operate normally. I want to clarify this with you, the UICR can be changed and the device can operate normally after a soft reset? There is no hard reset required for this?

Will I run into a problem like this with DFU (I.E. if I'm programming the device with DFU will it require a hard reset after changing the firmware)?

Thank you,

Nick

[Einar Thorsrud]

Hi Nick,

I see. Thank you for letting us know.

Nicholas_Nuti said:

Does the UICR not need a soft reset after writing to it? Typically when I write to it using the command line tools, I need to initiate a reset so that the device will operate normally. I want to clarify this with you, the UICR can be changed and the device can operate normally after a soft reset? There is no hard reset required for this?

Some of the registers in the UICR are only read after reset, so a change in those need a reset for it to take effect. That applies to changes in REG0 configuration, reset pin enable/disable, etc. But in those cases, a soft reset is enough. If you just write your own user data to available registers (typically serial number or similar), then there is no need to reset, and you can read the data back immediately after as you could any other flash region.

Einar