• State Verified Answer
  • Replies 2 replies
  • Subscribers 91 subscribers
  • Views 41 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 360756
Options

Invalid default MAC at first read - nRF7002

Antoine.B

Hi,

I'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 PCBA, the MAC readed is as below (MAC0.ADDRESS = 00:00:00:00:00:00):

TX: wifi_radio_ficr_prog otp_write_params 0x100 0x50FA50FA
RX: wifi_radio_ficr_prog otp_write_params 0x100 0x50FA50FA
RX: OTP Region is unprogrammed - program to enable R/W
RX: 
RX: Finished Writing OTP params
RX: uart:~$ [00:00:42.561,462] <inf> otp_prog: Written REGION_PROTECT0 (0x100) : 0x50fa50fa
TX: wifi_radio_ficr_prog otp_read_params
RX: wifi_radio_ficr_prog otp_read_params
RX: OTP Region is open for R/W
RX: 
RX: PRODTEST.FT.PROGVERSION = 0xff0700ff
RX: 
RX: PRODTEST.TRIM0 = 0x00090406
RX: PRODTEST.TRIM1 = 0x0009d407
RX: PRODTEST.TRIM2 = 0x0009d807
RX: PRODTEST.TRIM3 = 0x000f040b
RX: PRODTEST.TRIM4 = 0x000fd407
RX: PRODTEST.TRIM5 = 0x000fd807
RX: PRODTEST.TRIM6 = 0xffffffff
RX: PRODTEST.TRIM7 = 0xffffffff
RX: PRODTEST.TRIM8 = 0xffffffff
RX: PRODTEST.TRIM9 = 0xffffffff
RX: PRODTEST.TRIM10 = 0xffffffff
RX: PRODTEST.TRIM11 = 0xffffffff
RX: PRODTEST.TRIM12 = 0xffffffff
RX: PRODTEST.TRIM13 = 0xffffffff
RX: PRODTEST.TRIM14 = 0xffffffff
RX: 
RX: INFO.PART = 0x00007002
RX: INFO.VARIANT = 0x00423030
RX: 
RX: INFO.UUID0 = 0xd083f37a
RX: INFO.UUID1 = 0x11ee6f8d
RX: INFO.UUID2 = 0xcd5103cc
RX: INFO.UUID3 = 0x6f83c0a1
RX: 
RX: REGION.PROTECT0 = 0x50fa50fa
RX: REGION.PROTECT1 = 0x50fa50fa
RX: REGION.PROTECT2 = 0x50fa50fa
RX: REGION.PROTECT3 = 0x50fa50fa
RX: 
RX: MAC0.ADDRESS0 = 0x00000000
RX: MAC0.ADDRESS1 = 0x00000000
RX: MAC0.ADDRESS = 00:00:00:00:00:00
RX: 
RX: MAC1.ADDRESS0 = 0x00000000
RX: MAC1.ADDRESS1 = 0x00000000
RX: MAC1.ADDRESS = 00:00:00:00:00:00
RX: 
RX: CALIB.XO = 0x00
RX: REGION_DEFAULTS = 0x00000000
RX: 
RX: uart:~$ 

While a second test for the same PCBA will show the correct default MAC (MAC0.ADDRESS = ff:ff:ff:ff:ff:ff):

TX: wifi_radio_ficr_prog otp_write_params 0x100 0x50FA50FA
RX: wifi_radio_ficr_prog otp_write_params 0x100 0x50FA50FA
RX: OTP Region is open for R/W
RX: 
RX: Finished Writing OTP params
RX: uart:~$ [00:00:42.548,858] <inf> otp_prog: Written REGION_PROTECT0 (0x100) : 0x50fa50fa
TX: wifi_radio_ficr_prog otp_read_params
RX: wifi_radio_ficr_prog otp_read_params
RX: OTP Region is open for R/W
RX: 
RX: PRODTEST.FT.PROGVERSION = 0xff0700ff
RX: 
RX: PRODTEST.TRIM0 = 0x00090406
RX: PRODTEST.TRIM1 = 0x0009d407
RX: PRODTEST.TRIM2 = 0x0009d807
RX: PRODTEST.TRIM3 = 0x000f040b
RX: PRODTEST.TRIM4 = 0x000fd407
RX: PRODTEST.TRIM5 = 0x000fd807
RX: PRODTEST.TRIM6 = 0xffffffff
RX: PRODTEST.TRIM7 = 0xffffffff
RX: PRODTEST.TRIM8 = 0xffffffff
RX: PRODTEST.TRIM9 = 0xffffffff
RX: PRODTEST.TRIM10 = 0xffffffff
RX: PRODTEST.TRIM11 = 0xffffffff
RX: PRODTEST.TRIM12 = 0xffffffff
RX: PRODTEST.TRIM13 = 0xffffffff
RX: PRODTEST.TRIM14 = 0xffffffff
RX: 
RX: INFO.PART = 0x00007002
RX: INFO.VARIANT = 0x00423030
RX: 
RX: INFO.UUID0 = 0xd083f37a
RX: INFO.UUID1 = 0x11ee6f8d
RX: INFO.UUID2 = 0xcd5103cc
RX: INFO.UUID3 = 0x6f83c0a1
RX: 
RX: REGION.PROTECT0 = 0x50fa50fa
RX: REGION.PROTECT1 = 0x50fa50fa
RX: REGION.PROTECT2 = 0x50fa50fa
RX: REGION.PROTECT3 = 0x50fa50fa
RX: 
RX: MAC0.ADDRESS0 = 0xffffffff
RX: MAC0.ADDRESS1 = 0xffffffff
RX: MAC0.ADDRESS = ff:ff:ff:ff:ff:ff
RX: 
RX: MAC1.ADDRESS0 = 0xffffffff
RX: MAC1.ADDRESS1 = 0xffffffff
RX: MAC1.ADDRESS = ff:ff:ff:ff:ff:ff
RX: 
RX: CALIB.XO = 0xff
RX: REGION_DEFAULTS = 0xffffffff
RX: 
RX: uart:~$ 

The MAC cannot be written when it's at 00:00:00:00:00:00. The readback will show the correct default MAC.

What can cause the first read to not display ff:ff:ff:ff:ff:ff ?

Note:

- We already run production with the product and we didn't get this issue.

- I use TLL-RS232 USB/serial converter with python to automatize the testbench sequence and communicate with the target

Best regards,

Antoine

  • +1

    Hi Antoine,

    The main difference between the two tests is this:

    RX: OTP Region is unprogrammed - program to enable R/W

    RX: OTP Region is open for R/W

    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 otp_read_params() is called, the MAC and CALIB registers cannot be read, and return 0x00000000 instead of the actual OTP content.

    As stated in the  OTP memory programming documentation, a reboot is required after writing 0x50FA50FA. So the required programming sequence is:

    1. Set the protection registers with wifi_radio_ficr_prog otp_write_params 0x100 0x50FA50FA
    2. Reboot the device
    3. Write MAC / read OTP

    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.

    Best regards,
    Marte

  • 0 in reply to Marte Myrvold

    Hi Marte,

    Thank you for your response ! I just test it and it work fine after adding the reboot !

    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.

    Best regards,

    Antoine

Related
Terms of service