NRF7002 w/ NRF9160 project crash

RE: NRF7002 w/ NRF9160 project crash

RJengr — Fri, 12 Apr 2024 17:43:12 GMT

This issue has been resolved. The issue stems from CONFIG_NET_SOCKETS_OFFLOAD not only offloading the TCP/IP stack to hardware, but also setting the TCP/IP hardware as the default net interface. The Wifi scan sample code then uses net_if_get_default(), which actually returns the offloaded TCP/IP hardware instead of the Wifi interface, which causes a crash when trying to utilize wifi functions from net_mgmt. I was able to resolve this by using net_if_get_first_wifi() instead. I would suggest that Nordic revises their sample as using net_if_get_default() is not a deterministic implementation and other users may likely face the same issue.

RE: NRF7002 w/ NRF9160 project crash

NautDesigner — Thu, 11 Apr 2024 11:45:33 GMT

The main prj.conf in that sample has CONFIG_NET_SOCKETS enabled.

RE: NRF7002 w/ NRF9160 project crash

Simonr — Thu, 11 Apr 2024 11:42:26 GMT

Hi Paul

I haven't been able to dive into why CONFIG_NET_SOCKETS specifically causes this to occur yet, but can you instead try using the nrf7002ek-wifi-scan-only.conf as a template for setting up scanning on an nRF91+nRF7002 solution, where I see CONFIG_NET_SOCKETS isn't used at all.

Best regards,

Simon

RE: NRF7002 w/ NRF9160 project crash

NautDesigner — Wed, 10 Apr 2024 11:08:59 GMT

Correct. This works fine on the nRF7002DK without having to program OTP in V2.5.2. It's only on our custom board with nRF9160 and nRF7002 that we have this issue.

RE: NRF7002 w/ NRF9160 project crash

Simonr — Wed, 10 Apr 2024 07:14:23 GMT

Hi Paul

I just tried the scan sample in NCS 2.6.0 on an nRF7002DK. Just setting CONFIG_NET_SOCKETS=y does not change anything on my end, and it correctly runs both with and without this config. Let me know if there's anything else I can do to try and reproduce this on my end. Is it only when using the nRF91 and an nRF7002 together you're seeing this on your end?

...\v2.6.0\nrf\samples\wifi\scan

Best regards,

Simon

RE: NRF7002 w/ NRF9160 project crash

NautDesigner — Tue, 09 Apr 2024 08:04:15 GMT

Using the scan sample, just add CONFIG_NET_SOCKETS=y. Program crashes. Program OTP with MAC. Program continually reboots. Just trying to run the scan sample with CONFIG_NET_SOCKETS enabled.

SEGGER J-Link V7.94e - Real time terminal output
SEGGER J-Link V11.0, SN=851003323
Process: JLink.exe
[00:00:00.257,568] <inf> wifi_nrf: SPIM spi@a000: freq = 8 MHz

[00:00:00.257,965] <inf> wifi_nrf: SPIM spi@a000: latency = 0

*** Booting nRF Connect SDK v2.5.2 ***
Starting alertrax_nrf91_v3 with CPU frequency: 64 MHz
[00:00:00.257,629] <inf> wifi_nrf: SPIM spi@a000: freq = 8 MHz

[00:00:00.258,026] <inf> wifi_nrf: SPIM spi@a000: latency = 0

*** Booting nRF Connect SDK v2.5.2 ***
Starting alertrax_nrf91_v3 with CPU frequency: 64 MHz
[00:00:00.257,598] <inf> wifi_nrf: SPIM spi@a000: freq = 8 MHz

[00:00:00.257,995] <inf> wifi_nrf: SPIM spi@a000: latency = 0

*** Booting nRF Connect SDK v2.5.2 ***

RE: NRF7002 w/ NRF9160 project crash

Simonr — Tue, 09 Apr 2024 07:29:42 GMT

Hm, okay, these should be fine addresses from what I can see.

I discussed this with a colleague, and we need some more information on what exactly you're trying to do when running into this issue, as that's not clear here. You can check out this config overlay file for how to set up an nRF7002 to do scan only in a cellular application: https://github.com/nrfconnect/sdk-nrf/blob/v2.6.0/samples/cellular/nrf_cloud_multi_service/overlay-nrf7002ek-wifi-scan-only.conf

Best regards,

Simon

RE: NRF7002 w/ NRF9160 project crash

NautDesigner — Mon, 08 Apr 2024 12:21:19 GMT

Using aa:ce:36:2f:00:5a fails as well.

RE: NRF7002 w/ NRF9160 project crash

NautDesigner — Mon, 08 Apr 2024 11:04:51 GMT

That is not what we chose, somehow it came out that way. But it’s not working with the first MAC address either. What two MAC addresses would you like us to test with?

RE: NRF7002 w/ NRF9160 project crash

Simonr — Mon, 08 Apr 2024 08:04:15 GMT

I think this is because 00-00-00-00-00-04 is not a valid MAC address. Is there a reason you're setting this address specifically?

If you make up your own MAC address, you're supposed to set the 2's place bit (the "locally administered" bit) in the first byte, to differentiate it from a guaranteed globally unique MAC address. Usually the first three bytes a unicast MAC address is an "Organizationally Unique Identifier" (OUI) that the IEEE assigned to the manufacturer of your Ethernet device. Manufacturers are required to make sure they keep the last 3 bytes unique

Best regards,

Simon

RE: NRF7002 w/ NRF9160 project crash

NautDesigner — Mon, 08 Apr 2024 02:47:04 GMT

Using the MAC 00-00-00-00-00-04 doesn't work when used on another board either.

RE: NRF7002 w/ NRF9160 project crash

NautDesigner — Mon, 08 Apr 2024 02:11:40 GMT

If OTP is programmed, scan still dies if CONFIG_NET_SOCKETS=y is enabled.

ifi_radio_ficr_prog otp_write_params 0x100 0x50FA50FA.
reboot
wifi_radio_ficr_prog otp_write_params 0x120 0xFF36CEF0 0x4A00
wifi_radio_ficr_prog otp_write_params 0x128 0xFF36CEF0 0x4B00
wifi_radio_ficr_prog otp_write_params 0x100 0x00000000

Reading parameters show the MAC is set:

rtt:~$ wifi_radio_ficr_prog otp_read_params
OTP Region is locked!!!

PRODTEST.FT.PROGVERSION = 0xff0300ff

PRODTEST.TRIM0 = 0x00090410
PRODTEST.TRIM1 = 0x0009d40b
PRODTEST.TRIM2 = 0x0009d80b
PRODTEST.TRIM3 = 0x000f040c
PRODTEST.TRIM4 = 0x000fd408
PRODTEST.TRIM5 = 0x000fd808
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 = 0x56029f54
INFO.UUID1 = 0x11eddc0b
INFO.UUID2 = 0x306c04cc
INFO.UUID3 = 0x3d75ea4e

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

MAC0.ADDRESS0 = 0xff36cef0
MAC0.ADDRESS1 = 0x00004a00
MAC0.ADDRESS = f0:ce:36:ff:00:4a

MAC1.ADDRESS0 = 0xff36cef0
MAC1.ADDRESS1 = 0x00004b00
MAC1.ADDRESS = f0:ce:36:ff:00:4b

CALIB.XO = 0xff
REGION_DEFAULTS = 0xfffffff9

Is there another step that is missing?

RE: NRF7002 w/ NRF9160 project crash

Simonr — Mon, 25 Mar 2024 13:25:11 GMT

Hi RJ

From the log here it seems like the nRF7002 isn't prepared with OTP memory being readied/programmed on your end. Can you confirm that you've enabled OTP memory access with the steps described here: https://infocenter.nordicsemi.com/topic/nan_043/APP/nan_043/otp_programming.html

Best regards,

Simon