• State Verified Answer
  • Replies 13 replies
  • Subscribers 74 subscribers
  • Views 747 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 342892
Options

Wi-Fi Fundamentals Lesson 3 Exercise 2 - net_zperf: setsockopt SO_BINDTODEVICE error (-2)

zpm1066

Hello,

After successfully building Wi-Fi Fundamentals Lesson 3, Exercise 2 under nRF Connect SDK v2.9.1 & using nRF5340-DK with nRF7002-EK, I get the net_zperf: setsockopt SO_BINDTODEVICE error (-2).

I've also repeated by building and then running the provided l3_e2_sol. I ran the perf test on two completely different networks and got the same error. 

In both cases, nRF5340DK / nRF7002-EK connected successfully to the iperf server running on the same network as the nRF device. However, the nRF device was unable to receive any packets. I suspect because of the setsockopt SO_BINDTODEVICE error.

Please review the outputs below.

[00:00:00.305,877] <inf> wifi_nrf_bus: SPIM spi@a000: freq = 8 MHz
[00:00:00.305,908] <inf> wifi_nrf_bus: SPIM spi@a000: latency = 0
[00:00:00.425,659] <inf> wifi_nrf: Management buffer offload enabled

[00:00:00.557,586] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.557,586] <inf> fs_nvs: alloc wra: 0, fd0
[00:00:00.557,586] <inf> fs_nvs: data wra: 0, f4
*** Booting nRF Connect SDK v2.9.1-60d0d6c8d42d ***
*** Using Zephyr OS v3.7.99-ca954a6216c9 ***
[00:00:00.557,952] <inf> net_config: Initializing network
[00:00:00.557,983] <inf> net_config: Waiting interface 1 (0x20001e08) to be up...
[00:00:00.558,013] <inf> net_config: Running dhcpv4 client...
[00:00:00.558,288] <inf> Lesson3_Exercise2: Starting nrf5340dk with CPU frequency: 128 MHz
[00:00:00.558,471] <inf> wifi_supplicant: wpa_supplicant initialized
[00:00:01.533,355] <inf> wifi_mgmt_ext: Connection requested
[00:00:01.558,349] <inf> Lesson3_Exercise2: Waiting to connect to Wi-Fi
Connected
[00:00:07.383,575] <inf> net_dhcpv4: Received: 192.168.1.155
[00:00:07.383,636] <inf> net_config: IPv4 address: 192.168.1.155
[00:00:07.383,636] <inf> net_config: Lease time: 2592000 seconds
[00:00:07.383,666] <inf> net_config: Subnet: 255.255.255.0
[00:00:07.383,697] <inf> net_config: Router: 192.168.1.1
[00:00:07.383,758] <inf> Lesson3_Exercise2: Network connected
[00:00:10.383,880] <inf> Lesson3_Exercise2: IPv4 address 192.168.1.29
[00:00:10.383,880] <inf> Lesson3_Exercise2: Starting Wi-Fi throughput test: Zperf client
[00:00:10.383,911] <inf> Lesson3_Exercise2: New UDP session started
[00:00:10.384,063] <wrn> net_zperf: setsockopt SO_BINDTODEVICE error (-2)

[00:00:32.863,922] <inf> Lesson3_Exercise2: Wi-Fi throughput test: Upload completed!
[00:00:32.863,922] <inf> Lesson3_Exercise2: Upload results:
[00:00:32.863,922] <inf> Lesson3_Exercise2: 23536640 bytes in 20001 ms
[00:00:32.863,952] <inf> Lesson3_Exercise2: 22985 packets sent
[00:00:32.863,952] <inf> Lesson3_Exercise2: 82781 packets lost
[00:00:32.863,952] <inf> Lesson3_Exercise2: 0 packets received
[00:00:32.863,952] <inf> Lesson3_Exercise2: 9193 kbps throughput

iPerf server:

[ 2] local 192.168.1.29 port 5001 connected with 192.168.1.155 port 56794
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 2] 0.00-1.00 sec 577 KBytes 4.73 Mbits/sec 2.557 ms 544/1121 (49%)
[ 2] 1.00-2.00 sec 512 KBytes 4.19 Mbits/sec 2.488 ms 660/1172 (56%)
[ 2] 2.00-3.00 sec 612 KBytes 5.01 Mbits/sec 2.540 ms 536/1148 (47%)
[ 2] 3.00-4.00 sec 540 KBytes 4.42 Mbits/sec 3.276 ms 553/1093 (51%)
[ 2] 4.00-5.00 sec 620 KBytes 5.08 Mbits/sec 2.566 ms 602/1222 (49%)
[ 2] 5.00-6.00 sec 600 KBytes 4.92 Mbits/sec 2.505 ms 516/1116 (46%)
[ 2] 6.00-7.00 sec 604 KBytes 4.95 Mbits/sec 2.699 ms 559/1163 (48%)
[ 2] 7.00-8.00 sec 604 KBytes 4.95 Mbits/sec 2.481 ms 533/1137 (47%)
[ 2] 8.00-9.00 sec 597 KBytes 4.89 Mbits/sec 2.765 ms 564/1161 (49%)
[ 2] 9.00-10.00 sec 547 KBytes 4.48 Mbits/sec 2.528 ms 615/1162 (53%)
[ 2] 10.00-11.00 sec 608 KBytes 4.98 Mbits/sec 2.529 ms 554/1162 (48%)
[ 2] 11.00-12.00 sec 596 KBytes 4.88 Mbits/sec 2.671 ms 544/1140 (48%)
[ 2] 12.00-13.00 sec 596 KBytes 4.88 Mbits/sec 2.864 ms 527/1123 (47%)
[ 2] 13.00-14.00 sec 568 KBytes 4.65 Mbits/sec 2.673 ms 628/1196 (53%)
[ 2] 14.00-15.00 sec 608 KBytes 4.98 Mbits/sec 2.726 ms 534/1142 (47%)
[ 2] 15.00-16.00 sec 612 KBytes 5.01 Mbits/sec 2.562 ms 529/1141 (46%)
[ 2] 16.00-17.00 sec 512 KBytes 4.19 Mbits/sec 2.564 ms 650/1162 (56%)
[ 2] 17.00-18.00 sec 560 KBytes 4.59 Mbits/sec 2.566 ms 596/1156 (52%)
[ 2] 18.00-19.00 sec 560 KBytes 4.59 Mbits/sec 2.504 ms 589/1149 (51%)
[ 2] 19.00-20.00 sec 574 KBytes 4.70 Mbits/sec 3.580 ms 524/1098 (48%)
[ 2] 20.00-21.00 sec 0.000 Bytes 0.000 bits/sec 0.000 ms 0/0 (0%)
[ 2] 21.00-22.00 sec 0.000 Bytes 0.000 bits/sec 0.000 ms 0/0 (0%)
[ 2] 0.00-22.08 sec 11.3 MBytes 4.31 Mbits/sec 2.836 ms 11377/22985 (49%)

What would be the reason for the setsockopt error? Thank you.


Regards,
Ravi

  • 0 in reply to Marte Myrvold

    Hi Marte,


    Yes, I can confirm that the removal of the above Kconfig options no longer generates the ROU errors on device reset. Thank you.

    What is the RPU? It looks like it's an interface to the nRF70 Wi-Fi driver layers from the host.

    I'm trying to understand why removing the TF-M Kconfig fixes the RPU related errors. Any further info you can provide would be useful. I can see RPU APIs in the docs but nothing on the RPU.


    Kind Regards,
    Ravi 

  • 0 in reply to zpm1066

    Hi Ravi,

    It could be related to the GPIO forwarder to the network core. If you look at the pins used for the GPIO forwarder and UART1 for the nRF7002 DK vs the nRF5340 DK, you can see that there is some overlap in pins used on the nRF5340 DK, but not on the nRF7002 DK:

    nRF7002 DK (from nrf7002dk/nrf5340_cpuapp_common.dtsi and nrf7002dk/nrf5340_cpuapp_common-pinctrl.dtsi)

    gpio_fwd: nrf-gpio-forwarder {
	compatible = "nordic,nrf-gpio-forwarder";
	status = "okay";
	uart {
		gpios = <&gpio1 1 0>, <&gpio1 0 0>, <&gpio1 5 0>, <&gpio1 4 0>;
	};
};

uart1_default: uart1_default {
	group1 {
		psels = <NRF_PSEL(UART_TX, 1, 1)>;
	};
	group2 {
		psels = <NRF_PSEL(UART_RX, 1, 0)>;
		bias-pull-up;
	};
};

uart1_sleep: uart1_sleep {
	group1 {
		psels = <NRF_PSEL(UART_TX, 1, 1)>,
			<NRF_PSEL(UART_RX, 1, 0)>;
		low-power-enable;
	};
};

    nRF5340 DK (from nrf5340dk/nrf5340_cpuapp_common.dtsi and nrf5340dk/nrf5340_cpuapp_common-pinctrl.dtsi)

    gpio_fwd: nrf-gpio-forwarder {
	compatible = "nordic,nrf-gpio-forwarder";
	status = "okay";
	uart {
		gpios = <&gpio1 1 0>, <&gpio1 0 0>, <&gpio0 11 0>, <&gpio0 10 0>;
	};
};


uart1_default: uart1_default {
	group1 {
		psels = <NRF_PSEL(UART_TX, 1, 1)>,
			<NRF_PSEL(UART_RTS, 0, 11)>;
	};
	group2 {
		psels = <NRF_PSEL(UART_RX, 1, 0)>,
			<NRF_PSEL(UART_CTS, 0, 10)>;
		bias-pull-up;
	};
};

uart1_sleep: uart1_sleep {
	group1 {
		psels = <NRF_PSEL(UART_TX, 1, 1)>,
			<NRF_PSEL(UART_RX, 1, 0)>,
			<NRF_PSEL(UART_RTS, 0, 11)>,
			<NRF_PSEL(UART_CTS, 0, 10)>;
		low-power-enable;
	};
};

    So, disabling UART1 seems to affect the GPIO forwarder.

    Best regards,
    Marte

  • 0 in reply to Marte Myrvold

    Hi Marte,

    Thank you

    I'll go ahead and close this ticket. Your assistance and feedback I much appreciated. 



    Kind Regards,
    Ravi

Related
Terms of service