eclipse-threadx/getting-started

[MXCHIP] app can't connect to WiFi; default firmware has no problem

robgilliam opened this issue ยท 7 comments

My MXCHIP DevKit can connect to my 2.4GHz WiFi without any problems if I flash the v2.0.0 firmware to it, but the getting-started app fails to connect, with the join-result returned as 1024, which appears to indicate it can't see the network; see the output below, with reference to network IceBear:

**************************************************
** DOWNLOAD FIRMWARE v2.0.0 AND RESET THE BOARD **
**************************************************
[00]
************************************************
** MXChip - Microsoft IoT Developer Kit **
************************************************
You can 1. press Button A and reset to enter configuration mode.
        2. press Button B and reset to enter AP mode.

Wi-Fi IceBear connected.
Now is (UTC): Tue Feb 28 16:38:55 2023

>>> Failed to send telemetry data: Http fault.
0) Guest7B4786	Signal: -69	Enc type: 4
1) IceBear	Signal: -69	Enc type: 4
2) BT-JZATTF	Signal: -75	Enc type: 4
3) BT-JZATTF	Signal: -79	Enc type: 4
4) VM5611921	Signal: -80	Enc type: 4
5) SKYCHEY9	Signal: -81	Enc type: 4
6) TALKTALK73E565	Signal: -84	Enc type: 4
7) BTWi-fi	Signal: -84	Enc type: 7
8) BT-GRA625	Signal: -84	Enc type: 4
9) BTWi-fi	Signal: -84	Enc type: 7
>>> Failed to send telemetry data: Http fault.

******************************************************************
** BUILD AND DOWNLOAD 'getting-started' APP AND RESET THE BOARD **
******************************************************************
[00]Scanning I2C bus
	.........................0x190x1a...0x1e.0x20...........................0x3c...............................0x5c..0x5f..........0x6a.....................

Starting Azure thread


Initializing WiFi
	MAC address: C8:93:46:86:09:6C
SUCCESS: WiFi initialized

Connecting WiFi
	Connecting to SSID 'IceBear'
	Attempt 1...
	join_result = 1024
	Attempt 2...
	join_result = 1024
	Attempt 3...
	join_result = 1024
	Attempt 4...
	join_result = 1024
	Attempt 5...
	join_result = 1024

(etc.)

My network is set-up for WPA2; I'm assuming AES (but I've tried forcing-setting the TKIP flag with WPA2 just in case, which is no better), and the key (password) is definitely correct. What could I be missing? What should I check next?

Have you tried connecting to another 2.4GH wifi?

Yes it does indeed appear that it couldnt find the SSID. I'll take a look and see if I can find anything else.

I just tried switching it to my router's guest network (Guest7B4786 in the list above), but the result is the same.

FIXED

The problem was caused by the fact I'm in the UK, not the good ol' US of A, so I needed to tell the device to use a different country set-up by adding a country code to the wiced_country_code_t enumeration in wiced_sdk.h:

typedef enum
{
    WICED_COUNTRY_UNITED_KINGDOM = MK_CNTRY('G', 'B', 0), // add this line
    WICED_COUNTRY_UNITED_STATES = MK_CNTRY('U', 'S', 0)
} wiced_country_code_t;

then change the value chosen for WIFI_COUNTRY in wwd_networking.c:

#define WIFI_COUNTRY WICED_COUNTRY_UNITED_KINGDOM // was WICED_COUNTRY_UNITED_STATES

and I get successful connection to my WiFi network (and even successful telemetry data appearing in Azure IoT Central)

Thanks for investigating and letting me know, I'm guessing you are using a channel that is not part of the US spectrum. I'm a bit confused by why the client side cares about this, but I guess the wifi module can also act as an ad hoc server. I'll investigate whether there is a better country code option to use that wont run into this problem.

I believe that your router must have been using channel 12 or 13, which are typically not used here in the USA.

I pushed a change to use the world wide country code, which should support passive channel 12 + 13. If you get a chance, would you be able to check with this country code (take a look at main) and see if this also works?

World-wide country code "XX" (from main) is working for me as well ๐Ÿ‘