• 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

Parents
  • +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

Reply Children
No Data
Related
Terms of service