When launching aws examples for the IOT module with the MCUxpresso 10.1.1 debug , I keep blocked in the wifi initialization as follows:
0 0 [Tmr Svc] Starting key provisioning...
1 4 [Tmr Svc] Write root certificate...
2 7 [Tmr Svc] Write device private key...
3 27 [Tmr Svc] Write device certificate...
4 45 [Tmr Svc] Key provisioning done...
5 51 [Tmr Svc] Starting WiFi...
because WIFI_On() always fails so code is blocked in the following assert:
result = WIFI_On();
assert(eWiFiSuccess == result);
Nevertheless, if not using MCUXpresso, and I unplug the usb iotmodule and re-plug and press reset button the wifi initalization is OK:
0 0 [Tmr Svc] Starting key provisioning...
1 0 [Tmr Svc] Write root certificate...
2 1 [Tmr Svc] Write device private key...
3 12 [Tmr Svc] Write device certificate...
4 21 [Tmr Svc] Key provisioning done...
5 23 [Tmr Svc] Starting WiFi...
6 1652 [Tmr Svc] WiFi module initialized.
I am using MacOS High Sierra
Thank you in advance for your support,
Roberto
Solved! Go to Solution.
Hello Roberto!
We have tested the example in MacOS High Sierra using MCUXpresso 10.1.1 IDE and JLINK. We were able to reproduce what you mentioned, the demo won't connect to the WIFI if you run the program immediately after launching the debug session. We were able to run the example successfully while debugging if we first click the RESTART button on MCUXpresso and then run/debug the example normally. This behavior was already reported to the IDE team, meanwhile you can use the workaround mentioned above and let us know the results on your side.
Regards,
Victor Jimenez.
Hello Roberto!
We have tested the example in MacOS High Sierra using MCUXpresso 10.1.1 IDE and JLINK. We were able to reproduce what you mentioned, the demo won't connect to the WIFI if you run the program immediately after launching the debug session. We were able to run the example successfully while debugging if we first click the RESTART button on MCUXpresso and then run/debug the example normally. This behavior was already reported to the IDE team, meanwhile you can use the workaround mentioned above and let us know the results on your side.
Regards,
Victor Jimenez.
This issue was actually completely fixed by SEGGER's Jlink_v6.32b release. We have tested and confirmed this now.
Victor, thank you very much for the workaround. It worked as expected.
Hello Roberto!
When you have the MCUXpresso Open are you trying to debug the program? The communication for this DEMO is USB, so if you stop in the debug mode this will break the communication and the program won't work correctly. So I recommend you to don't add break points and don't debug step by step. That's the reason that when you stop the debug session (close MCUXpresso) and click on reset the program works fine. It's not necessary that you close MCUXpresso, just flash the program to your board with the debug session but instead of run the application from the debug session click on stop and finally reset your board.
Hope it helps!
Have a great day,
Victor.
Thank you Victor for your prompt response but I am not debugging step by step. The only break point I have is default one at the very first line in main. My problem is not related with the usb communication; I get the log information from the usb successfully. My real issue is the WiFI module initialization. It fails if the program is launched in debug mode from MCUXpresso (even with no break points).
If I can not use MCUXpresso to debug... what is the point of the IDE ? especially if I want to understand the way the code works?
Regards,
Roberto
Hi Roberto - we'll need to run some checks on a Mac to see if there is some peculiarity related to that platform and get back to you.
I haven't been able to try this yet, but to eliminate it as a possibility (and to give you something to try in the meantime), could you please check/try this fix for a known issue with MacOS (from the IDE installation guide):
1.3.1 Mac OS X Sierra – Unexpected Delays during Debug Operations
Mac OS X Sierra installations may experience an approximately 5-second delay when a call to get the localhost address is made from Java. This call is used within MCUXpresso IDE
when establishing a debug connection for LinkServer, P&E or SEGGER. Therefore, if a delay is experienced during a debug operation, the following fix may be required.
First, launch a Terminal session and enter the command hostname, which will return something of
the form:
~$ hostname
user-Mac.local
Next, edit your /etc/hosts file and add the returned hostname after the localhost entries as shown
below:
127.0.0.1 localhost user-Mac.local
::1 localhost user-Mac.local
Save the etc/hosts file. Once this change has been made, the 5-second delay should be reduced to a few milliseconds. Further information about this issue can be obtained by performing a web search of the form MacOS Sierra Java localhost slow.
Hi Brendon,
Yes I am using Mac OS High Sierra 10.13.3, and I already had the fix you propose in the hosts file (from older issues:-).
I have a JLINK probe and I work with other cusmtom NXP boards and MCUXpresso without problems.
Actually, the issue is related WIFI initalization; I can debug with MCUXpresso, but in that case, wifi initalization always fails, the assert is false: (It is a shame to have to install another IDE, I really prefer to keep working withMCUXpresso as I do for the rest of my projects)
result = WIFI_On();
assert(eWiFiSuccess == result);