NUCLEO_IDW01M1 gets stuck to error state #18
Comments
|
Which FW version do you use on the expansion board (see here)? |
|
Tested with FW versions 3.5.3 and 3.6.0 |
|
I am also running into this when using an NUCLEO_L496ZG board, it says: SPWF> ERROR: Should never happen! (_wait_console_active, 246) When using the NUCLEO_L476RG board it works correctly. |
|
@betzw |
|
Is the SPWF> ERROR happening with both FW versions? |
|
Yes, with both FW versions. |
|
Well, the error you are observing happens typically when the serial communication fails and is typically due to a wrong configuration of RX/TX pins. In your case it seems rather to be something like the module FW crashing, maybe due to the mess that happens when there is a stack overflow and maybe as a consequence you are sending corrupted AT commands to the module which are not handled correctly. |
|
OK. Thanks for the explanation. |
|
Does your OK mean that we can close this issue? |
|
Is it possible to update the driver SW so that it can recover the module from this state? Normal reset or power cycle doesn't help. |
|
Well, to me it's actually hard to understand that a HW reset or power cycling does not help, therefore I wouldn't what to do ... or better, I would like to understand what actually happens and not only make assumptions, which means I would need to reproduce the situation here in my office, but until today I wasn't able to do so :-( |
|
Here is an example how to reproduce the issue. Build the Greentea tests Run the greentea tests until you see the error SPWF> ERROR: Should never happen! (_wait_console_active, 246)
I need only 2-4 test runs to reproduce the issue. |
|
Would it be possible for you to send me the full execution trace of a very verbose test run? |
|
Full trace from test run which reproduces the issue: |
|
I just can't see the |
|
Found it ... sorry! |
|
Could you pls. check if you have applied the following modifications on the tests: |
|
Above changes seem to fix the issue #17 but I'm worried that there might be other cases where the WiFi shield ends up to non-functional state. So it would be better if the driver is able to recover from the error SPWF> ERROR: Should never happen! (_wait_console_active, 246). |
|
Well, from what you wrote some time ago
I can hardly imagine how you can recover from such a fault by SW/driver. |
|
@betzw so no firmware fix to be expected for this issue. |
|
Very unlikely. |
|
Can we close this issue? |
|
@SeppoTakalo should this be handled in a way that it is marked as a known restriction to README.md and once it's done this ticket is closed? |
|
Why not just leave this open, if the root cause is not fixed. |
|
Simply because the root cause is not the driver. |
|
What it is then? If this is not reported here, where would it be reported? |
|
I do not know as I never managed to reproduce the issue. |
And it seems to be just a worry of @juhaylinen |
|
@jflynn129 seems to have the same issue, to be exact. |
|
@VeijoPesonen I ended up using a different WiFi board because this st WiFi board will not work with the nucleo l496zg which is what I was targeting. Seems that this WiFi board has a limited selection of compatible nucleo boards. |
|
Regarding @jflynn129 comment pls. refer to discussion #19. |
|
@betzw Did you ever run the tests? This happens every night in our CI. Just run Mbed OS socket tests. |
On my side theses tests were passing. |
|
Btw, I needed to modify the |
|
Any update on this from ARM side? |
|
No changes should be required, or are allowed on test cases. We run same testcases on all boards without modification and there are many that pass TCP and UDP tests. |
|
Well, I am just wondering how WiFi boards in general should connect to the WiFi network/service without credentials (including SSID)? |
|
Furthermore, I believe that the |
If you mean the model where data is only processed when sending/receiving that is the case. But if you use separate thread/global event queue like with esp8266-driver(PR ARMmbed/esp8266-driver#106) then it's possible to pass the test cases in question. As an example test cases results when using ESP8266 Wi-Fi module. |
|
Well, I think its more about that the following methods are new to me and therefore not (yet) supported: |
|
@VeijoPesonen, |
|
Have mbed_app.json like this: {
"config": {
"wifi-secure-ssid": {
"help": "WiFi SSID for WPA2 secured network",
"value": "\"systest\""
},
"wifi-unsecure-ssid": {
"help": "WiFi SSID for unsecure netwrok",
"value": "\"echonet\""
},
"wifi-password": {
"help": "WiFi Password",
"value": "\"RaaSysT35T\""
},
"wifi-secure-protocol": {
"help": "WiFi security protocol, valid values are WEP, WPA, WPA2, WPA/WPA2",
"value": "\"WPA2\""
},
"wifi-ch-secure": {
"help": "Channel number of secure SSID",
"value": 6
},
"wifi-ch-unsecure": {
"help": "Channel number of unsecure SSID",
"value": 6
},
"wifi-tx": {
"help": "TX pin for serial connection to external device",
"value": "D1"
},
"wifi-rx": {
"help": "RX pin for serial connection to external device",
"value": "D0"
},
"ap-mac-secure": {
"help": "BSSID of secure AP in form of AA:BB:CC:DD:EE:FF",
"value": "\"80:2a:a8:8a:e9:13\""
},
"ap-mac-unsecure": {
"help": "BSSID of unsecure AP in form of \"AA:BB:CC:DD:EE:FF\"",
"value": "\"58:8b:f3:99:c2:08\""
},
"max-scan-size": {
"help": "How many networks may appear in Wifi scan result",
"value": 30
},
"echo-server-addr" : {
"help" : "IP address of echo server",
"value" : "\"echo.mbedcloudtesting.com\""
},
"echo-server-port" : {
"help" : "Port of echo server",
"value" : "7"
}
},
"target_overrides": {
"*": {
"lwip.ipv4-enabled": true,
"lwip.ipv6-enabled": false,
"target.network-default-interface-type": "WIFI",
"nsapi.default-wifi-ssid": "MBED_CONF_APP_WIFI_SECURE_SSID",
"nsapi.default-wifi-password": "MBED_CONF_APP_WIFI_PASSWORD",
"nsapi.default-wifi-security": "WPA_WPA2"
},
"K64F": {
"esp8266.provide-default": true
},
"NUCLEO_F401RE": {
"idw0xx1.provide-default": true,
"idw0xx1.tx": "D8",
"idw0xx1.rx": "D2",
"drivers.uart-serial-txbuf-size": 512,
"drivers.uart-serial-rxbuf-size": 512
},
"DISCO_L475VG_IOT01A": {
"ism43362.provide-default": true
}
},
"macros": ["MBED_EXTENDED_TESTS"]
} |
|
Seems as if I am completely stupid or expressing myself terribly badly ... Anyway, I am looking for the place in the test sources where the above config values for WiFi (above all SSID, pwd, and protocol) get used in order to make the tests work also for WiFi modules. |
|
Socket tests are relying on those That class is instantiated here: https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/NetworkInterfaceDefaults.cpp#L86..L104 so the Socket test cases do not touch the configuration anymore. Then the WIFI tests use those So some configuration values appear twice in your app-json, because they satisfy different API levels. |
|
OK, got it! Will try. |
|
Well are part of API so should be added. Socket options are basically always implementation specific, so it is fine to return |
@avilei, can you pls. provide some information to @SeppoTakalo if and when ST might implement these additional API functionality? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue is related to #17
When I run Greentea netsocket and WiFi tests and the hardfault happens, IDW01M1 may end up to a non-functional state and return below errors
SPWF> ERROR: Should never happen!(_wait_console_active, 246)
-3012 -> NSAPI_ERROR_DEVICE_ERROR
Reset, re-flashing the binary or power cycle doesn't help.
Only solution found so far to recover the WiFi shield is to use WiFi_VCOM_F401RE binary and enter below AT commands:
“AT&F”
“AT+CFUN=1”
The text was updated successfully, but these errors were encountered: