Writing to UICR + software reset

RE: Writing to UICR + software reset

Nicholas_Nuti — Fri, 12 Jun 2020 20:56:48 GMT

Hi Einar,

Ultimately, I think this is what I wanted to know. Thank you so much for the helpful information!

Thank you,

Nick

RE: Writing to UICR + software reset

Einar Thorsrud — Thu, 11 Jun 2020 08:12:38 GMT

Hi Nick,

[quote user="Nicholas_Nuti"]Thanks for the information! Im hoping that the registers that I'm using wont require a reset; do you know which do need a soft reset?[/quote]

All the UICR registers that configure HW, which are those with an offset of 0x200 or higher require a reset to take effect since it is only read during startup.

Einar

RE: Writing to UICR + software reset

Nicholas_Nuti — Wed, 10 Jun 2020 17:21:01 GMT

Hi Einar,

[quote userid="7377" url="~/f/nordic-q-a/62252/writing-to-uicr-software-reset/253923"]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.[/quote]

Thanks for the information! Im hoping that the registers that I'm using wont require a reset; do you know which do need a soft reset?

[quote userid="7377" url="~/f/nordic-q-a/62252/writing-to-uicr-software-reset/253923"]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.[/quote]

That's great to hear.

Thank you for the info,

Nick

RE: Writing to UICR + software reset

Einar Thorsrud — Tue, 09 Jun 2020 06:26:42 GMT

Hi Nick,

I see. Thank you for letting us know.

[quote user="Nicholas_Nuti"]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?[/quote]

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

RE: Writing to UICR + software reset

Nicholas_Nuti — Mon, 08 Jun 2020 20:19:57 GMT

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

RE: Writing to UICR + software reset

Nicholas_Nuti — Mon, 08 Jun 2020 19:30:57 GMT

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!

RE: Writing to UICR + software reset

Einar Thorsrud — Mon, 08 Jun 2020 08:50:08 GMT

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

RE: Writing to UICR + software reset

hmolesworth — Sat, 06 Jun 2020 17:05:48 GMT

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,