<?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>Invalid default MAC at first read - nRF7002</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/128411/invalid-default-mac-at-first-read---nrf7002</link><description>Hi, 
 
 I&amp;#39;m using nRF5340 + nRF7002 for project that use wifi but I have issue while reading the default MAC before recording a new one. 
 The products are tested inside a testbench (each test is the exact same sequence) and for the first test of each</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 10 Jun 2026 10:17:48 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/128411/invalid-default-mac-at-first-read---nrf7002" /><item><title>RE: Invalid default MAC at first read - nRF7002</title><link>https://devzone.nordicsemi.com/thread/567687?ContentTypeID=1</link><pubDate>Wed, 10 Jun 2026 10:17:48 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ca5f72b8-85de-4b43-9180-8709adc9fb2a</guid><dc:creator>Antoine.B</dc:creator><description>&lt;p&gt;Hi Marte,&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Thank you for your response ! I just test it and it work fine after adding the reboot !&lt;/p&gt;
&lt;p&gt;Is that a recent update of the documentation ? Using nRF7002 from another lot (one year ago), this reboot was not mandatory as the production went fine without it.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Antoine&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Invalid default MAC at first read - nRF7002</title><link>https://devzone.nordicsemi.com/thread/567681?ContentTypeID=1</link><pubDate>Wed, 10 Jun 2026 09:29:07 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:eed3a608-9018-45bd-ad55-e207519404cf</guid><dc:creator>Marte Myrvold</dc:creator><description>&lt;p&gt;Hi&amp;nbsp;Antoine,&lt;/p&gt;
&lt;p&gt;The main difference between the two tests is this:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="text"&gt;RX: OTP Region is unprogrammed - program to enable R/W&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="text"&gt;RX: OTP Region is open for R/W&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;So in the first test, the REGION.PROTECT registers are in the unprogrammed/disabled state (0xFFFFFFFF), which means that neither read nor write access is enabled for the customer-programmable region. Therefore, when&amp;nbsp;otp_read_params() is called, the MAC and CALIB registers cannot be read, and return&amp;nbsp;0x00000000 instead of the actual OTP content.&lt;/p&gt;
&lt;p&gt;As stated in the&amp;nbsp;&lt;a href="https://docs.nordicsemi.com/r/bundle/nan_043/page/app/nan_043/otp_programming.html"&gt; OTP memory programming&lt;/a&gt;&amp;nbsp;documentation, a reboot is required after writing&amp;nbsp;0x50FA50FA. So the required programming sequence is:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Set the protection registers with&amp;nbsp;&lt;span&gt;&lt;code&gt;wifi_radio_ficr_prog otp_write_params 0x100 0x50FA50FA&lt;/code&gt;&lt;/span&gt;&lt;/li&gt;
&lt;li&gt;Reboot the device&lt;/li&gt;
&lt;li&gt;Write MAC / read OTP&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;So the fix is to add a device reboot step in your test sequence after otp_write_params 0x100 0x50FA50FA and before otp_read_params.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;br /&gt;Marte&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>