Community news, upcoming events and general discussions
Threads: 31 Posts: 81
Get technical support from the community
Threads: 1048 Posts: 5780
Threads: 15 Posts: 54
Tell us how to make XDK better!
Threads: 35 Posts: 117
Share and discuss community member projects
Threads: 49 Posts: 237
I have a customer who is working on a project that will be continually powered by the USB cable. In his particular use case, loss of the wifi network causes the XDK to hang and it needs to be restarted. The workbench version 3.0.1 doesn't have the Watchdog feature implemented yet, so a manual restart is required, without a more extensive fix (which we are working on). A quick and simple fix would be to just remove the battery. However this creates another issue where the Wi-Fi module won't initialize. The following error is returned from the WlanConnect_Init funciton:
INFO | XDK DEVICE 1: Severe error from wifi package, Error code: 8 and module ID is :1 INFO | XDK DEVICE 1: Error in package ID: 10 Severity code: 2 Error code: 8, module ID : 1
Since this function is in a library, we can't see the source code to know what the error means. Can you shed some light on this error and please inform me why, when the battery is removed, the Wi-Fi stops working. I know it is not a power issue as the wifi module is still supplied iwth power (checked this with a Fluke meter).
Thank you for your help
Hello Chris, I will gladly help to solve the issue of your customer and for that, I would like to know more about his use case. You explained that the XDK will get stuck after a loss of the Wi-Fi connection. I would guess that this issue is more related to memory management, as I see no reason for the XDK to get stuck from losing the connection. Instead, I imagine that a stack-overflow would be the culprit. As such, I would like to know what exactly you mean by the XDK getting stuck. Does an assert stop the task, is it a stack overflow or is it just a function-call blocking the task? A reboot of the XDK would solve the symptom, but not really the cause of the issue. It would be also possible within the XDK application and would not need to be done manually, especially not by removing the battery. I am not quite sure if the XDK would turn off, if the battery is removed. I assume that the battery is bypassed, if the XDK has an active USB connection. To do the software reset you only would need to include the interface BCDS_BSP_Board.h and then call the function BSP_Board_SoftReset(). Please note that this call makes an immediate reset of the XDK and doesn't offer the same functionality as a watchdog would do. And this would only work if the XDK does not get stuck due to a stack overflow. Regarding the loss of the Wi-Fi connection, could this issue perhaps not be solved by simply implementing a routine, which checks if a Wi-Fi connection is still active, and if it isn't, the XDK initiates a reconnect? If that is an option, I will gladly provide the implementation of the routine for normal WPA and Enterprise Wi-Fi networks. Please let me know if that helps you and your costumer and feel free to ask if you have further concerns or questions, I can help you with. Kind regards, Franjo
While I appreciate the feedback here, I would like to keep this thread to the topic at hand please. Why, where, and how we are getting stuck is not the issue at hand, it is more the backstory. We are already working on and have started implementing a solution for them to solve this issue properly. In fact we are using some of the methods you described. If we want, we should start another ticket to discuss Wi-Fi issues and solutions.
That all being said, can we please look into the issue I am seeing with the battery removal? Since we cannot look at the source code for the WlanConnect_Init function, can you shed some light into what the errors mean and why remvoing the battery keeps the Wi-Fi module from initializing? As I mentioned, the Wi-Fi module still has power without the battery, so it doens't make sense that it wouldn't initialize to me.
I think I misunderstood you a little bit since your backstory led me to think that you might be interested in different solutions as well.
Regarding the removal of the battery and the start of the Wi-Fi module, I guess that is more an electrical issue than a software issue.
Please note that when removing the battery, a correct function can not be assured any more. This applies to any hardware change related to the XDK.
The function WlanConnect_Init() does not only initialize the necessary WLAN modules on the XDK but also boot up the CC3100 Wi-Fi chip. I guess that the boot up of the CC3100 is the cause, as to why the function throws an error stating that the modules could not be initialized.
I guess that the CC3100 needs a high current to be able to boot up. The internal Li-Ion battery is able to provide 500 mA maximally. By disabling it, you need to ensure that your external supply source is able to provide that current as well. If you used your laptop, that might be the reason why the CC3100 cannot start up. Please note that notebooks are limited to only provide 100 mA.
The CC3100 requires around 200 - 250 mA to become fully operational.
To solve the issue, I would recommend to using a suitable external source, for example, a USB to electricity outlet connector which can provide 500 mA to 1 A. Alternatively, you still have the option of enabling the internal battery again to provide the necessary boot up current.
Please let me know if that was helpful and do not hesitate to ask if you have further questions.
Kind regards, Franjo
Thank you for this advice. I was able to test this with an external power source that can supply up to 2.1A of power, however the results are not that much different. While I cannot see the errors in the console window anymore, I do know that I don't get past the wifi initialization stage still (I set up some LEDs to tell me my current state. So unfortunately this didn't solve the issue.
I understand that modifying the Hardware can effect the performance of the software, so I was wondering if we knew why the battery change affected the outcome. My next thought is that is has to do with the Charge Controller. The TS signal should not be left floating, but it is when the battery is removed, this could be having the adverse affects on the system. Thank you for you help.
Dear XDK community,
Chris contacted me via email to exchange crucial information about his application to narrow the issue down, he doesn't want to share with the XDK community.
I will take a deeper look into that and share the suitable solution for the issue itself with the XDK community.