[nRF7002EK] Unable to read mac address

[Sagar.K]

Hello,

Development Environment :

SDK version: nRF Connect SDK v2.7.0

Toolchain version: nRF Connect SDK Toolchain v2.7.0

Development environment: Ubuntu 22.04

Development tool: Visual Studio Code

Development board: nrf7002dk_nrf5340_cpuapp

Example refference path: ~/ncs/v2.7.0/nrf/samples/wifi/sta

We are using nRF7002EK for evaluation purpose. Earlier we were able to connect to the wifi router using this module. But, now when we flash the mentioned sample code. We are not able to read the mac address over QSPI interface. we are getting 0s for all mac address.

When we tried to check if OTP memory is working or not we got the following response.

 

from here we got to know that this is an irreversible state. 

So, is there a way we can replace only the OTP memory on the nRF7002EK, as it will be a suitable alternative for us rather than replacing the whole module. If yes, can you please suggest a part no for an OTP memory.

Thank you.

[Elfving]

Hi Sagar,

So, is there a way we can replace only the OTP memory on the nRF7002EK, as it will be a suitable alternative for us rather than replacing the while module. If yes, can you please suggest a part no of the module.

I might be misunderstanding you here, but the OTP memory is not another IC on the nRF7002EK - it is in the nRF7002.

But I am also a bit confused as to how you ran into this issue if the EK module used to run well. Did you try writing to the OTP? The OTP should be already written to on the EKs, there is no need to write to it again.

Another thing that could add to the confusion here is that you are running an nRF7002EK along with an nRF7002DK. That should be possible of course, though I guess it might be possible that you are using the nRF7 on the DK instead of on the EK without you being aware of it. Any reason why you are using the two nRF7s?

Regards,

Elfving

[Sagar.K]

Hello Elfving 

Elfving said:

But I am also a bit confused as to how you ran into this issue if the EK module used to run well. Did you try writing to the OTP?

No. We didn't try writing to the OTP memory When it was working. We are also not quite sure, why we ran into this issue. is it possible that an ESD charge might create this type of issue ?

Elfving said:

Any reason why you are using the two nRF7s?

No, we are not using two nRF7s. We are just using the nRF5340DK and nRF7002EK, these two are interfaced over QSPI interface. We are using  nrf7002dk_nrf5340_cpuapp board config for build purpose only as it has support for nRF7002 interfacing over QSPI by default. we didn't use the nRF7002EK as a shield argument because it is configured to use SPI interface for nRF7002.

Hope this will clear the confusion. Now, coming to the main question. Is there a way to recover from this state ?

Thank you.

[Elfving]

Sagar.K said:

is it possible that an ESD charge might create this type of issue ?

I have never heard of that happening atleast.

Sagar.K said:

No, we are not using two nRF7s. We are just using the nRF5340DK and nRF7002EK, these two are interfaced over QSPI interface. We are using  nrf7002dk_nrf5340_cpuapp board config for build purpose only as it has support for nRF7002 interfacing over QSPI by default. we didn't use the nRF7002EK as a shield argument because it is configured to use SPI interface for nRF7002.

While I am not sure that would work, why not rather use the nRF7002 on the nRF7002Dk? That one is connected over QSPI.

Sagar.K said:

Hope this will clear the confusion. Now, coming to the main question. Is there a way to recover from this state ?

Can you give me the output when trying to read the OTP, not write to it?

Regards,

Elfving

[Sagar.K]

Elfving said:

While I am not sure that would work, why not rather use the nRF7002 on the nRF7002Dk? That one is connected over QSPI.

we don't have an nRF7002DK as of now, so we are using the mentioned approach and it is working without any issues.

Elfving said:

Can you give me the output when trying to read the OTP, not write to it?

Providing the output below :

uart:~$ wifi_radio_ficr_prog otp_read_params
OTP Region is in invalid state

PRODTEST.FT.PROGVERSION = 0xff0300ff

PRODTEST.TRIM0 = 0x090d0009
PRODTEST.TRIM1 = 0x0009d40b
PRODTEST.TRIM2 = 0x0009d80b
PRODTEST.TRIM3 = 0x040c0904
PRODTEST.TRIM4 = 0xd40809d4
PRODTEST.TRIM5 = 0xd80809d8
PRODTEST.TRIM6 = 0xffffffff
PRODTEST.TRIM7 = 0xffffffff
PRODTEST.TRIM8 = 0xffffffff
PRODTEST.TRIM9 = 0xffffffff
PRODTEST.TRIM10 = 0xffffffff
PRODTEST.TRIM11 = 0xffffffff
PRODTEST.TRIM12 = 0xffffffff
PRODTEST.TRIM13 = 0xffffffff
PRODTEST.TRIM14 = 0xffffffff

INFO.PART = 0x00007002
INFO.VARIANT = 0x00423030

INFO.UUID0 = 0x78f4e38f
INFO.UUID1 = 0x11edcb69
INFO.UUID2 = 0x2eb304cc
INFO.UUID3 = 0x258a4998

REGION.PROTECT0 = 0x50099550
REGION.PROTECT1 = 0x50099550
REGION.PROTECT2 = 0x50099550
REGION.PROTECT3 = 0x50099550

MAC0.ADDRESS0 = 0xe30d60e3
MAC0.ADDRESS1 = 0x00004950
MAC0.ADDRESS = e3:60:0d:e3:50:49

MAC1.ADDRESS0 = 0xe30d60e3
MAC1.ADDRESS1 = 0x00004a50
MAC1.ADDRESS = e3:60:0d:e3:50:4a

CALIB.XO = 0x29
REGION_DEFAULTS = 0xfffffff1

Thank you.

[Elfving]

Sagar.K said:

No, we are not using two nRF7s. We are just using the nRF5340DK and nRF7002EK, these two are interfaced over QSPI interface. We are using  nrf7002dk_nrf5340_cpuapp board config for build purpose only as it has support for nRF7002 interfacing over QSPI by default. we didn't use the nRF7002EK as a shield argument because it is configured to use SPI interface for nRF7002.

I guess as long as it works it is fine. Though using the EK as a shield, and then connecting it like this is the recommended way when using QSPI. 

Sagar.K said:

Providing the output below :

Looks like there is something wrong with the OTP, like you show in the OP it is supposed to be 0x50FA50FA. I guess ESD could be the issue, as I don't see what else could have caused this. 

Regards,

Elfving