<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Impact of eraseuicr on Bootloader</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/56298/impact-of-eraseuicr-on-bootloader</link><description>Hello, 
 
 I am using nRF52840, SDK_16.0.0, SoftDevice S140 V7.0.1 and Segger for flashing the image. I am using ‘ble_app_blinky’. 
 
 In our setup we load merged hex file with “MBR + SoftDevice” + BLE application + “Secure Serial Bootloader” + “Bootloader</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 07 Jan 2020 15:17:14 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/56298/impact-of-eraseuicr-on-bootloader" /><item><title>RE: Impact of eraseuicr on Bootloader</title><link>https://devzone.nordicsemi.com/thread/227974?ContentTypeID=1</link><pubDate>Tue, 07 Jan 2020 15:17:14 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:18f15003-b967-4de2-8991-ba53ebec5a50</guid><dc:creator>beemavishnu</dc:creator><description>&lt;p&gt;Thank a lot for your quick and detailed explanation.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Impact of eraseuicr on Bootloader</title><link>https://devzone.nordicsemi.com/thread/227973?ContentTypeID=1</link><pubDate>Tue, 07 Jan 2020 15:14:00 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:9ab16719-d7e0-410b-8b6d-10e00e937cdb</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Hello Vishnu,&lt;/p&gt;
&lt;p&gt;1) The UICR is not written during production, but there is another set of registers, the FICR registers. The FICR registers should not be tampered with. They are in fact written during the production of the chip. But the UICR you are &amp;quot;free to use as you like&amp;quot;. At least almost. You can see &lt;a href="https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Fuicr.html&amp;amp;cp=4_0_0_3_4" rel="noopener noreferrer" target="_blank"&gt;here&lt;/a&gt;&amp;nbsp;that there are some registers that are reserved for Nordic Firmware design, and some registers that are just reserved.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;But as I mentioned, the UICR is not programmed during the production of the chips. In addition, every time you run &amp;quot;nrfjprog --eraseall&amp;quot;, the UICR registers are also erased. (the FICR registers are not erased using --eraseall.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;2) Yes. That is probably what you are seeing. You mention a bootloader, and that is probably the reason it fails when you erase the UICR after programming your bootloader hex file, and an application that supports a bootloader. You see, the bootloader uses one of the UICR registers to hold the start address of the bootloader, and some applications such as the buttonless_dfu uses this register to check that there is a bootloader present. So the reason it worked before you erased the UICR is that the bootloader hex file also will write to the UICR, or the &lt;a href="https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Fuicr.html&amp;amp;cp=4_0_0_3_4_0_0&amp;amp;anchor=register.NRFFW-0-12" rel="noopener noreferrer" target="_blank"&gt;NRFFW&lt;/a&gt;&amp;nbsp;register, to be more precise, to tell the application and softdevice where the bootloader starts.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;You can check what is stored in the uicr after you programmed the merged hex file by using &amp;quot;nrfjprog --readuicr my_uicr.hex&amp;quot;. You will see something like this (except this is from an nRF52832) :&lt;/p&gt;
&lt;p&gt;&lt;a href="https://devzone.nordicsemi.com/cfs-file/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-940b137290b948c28b062789e561527f/my_5F00_uicr.hex"&gt;devzone.nordicsemi.com/.../my_5F00_uicr.hex&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;You can see that there is also something around 0x10001200, which is the reset button configurations, which is also stored in the UICR.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;So there are a lot of registers in the UICR that is reserved for the customers (you), but they are intended to be written to in (your) production, and then remain the same for the lifetime of the product.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Edvin&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>