Hi,
since I am working on a low-power project, I would like to use the stop() function of the CC3000 library.
However, after issuing the stop()-command, the CC3000 refuses to work again - the next time Arduino wants to talk to the WiFi chip, it gets no response: When trying to read the the firmware version it will not return from nvmem_read_sp_version().
Only a reset gets the CC3000 running again.
I am working on an Arduino Diecimila with an Atmega328. I checked 'buildtest' and 'ntpServer', both work like a charm.
Diving into the libraries I noticed a funny thing: stop() in Adafruit_CC3000.cpp calls wlan_stop, but does not reset _initialised. Then, when calling begin(), this function returns immediately, since _initialised is still 'true'. It will never call wlan_init() and wlan_start().
Removing the check for _initialised seems to do the trick, but I am not sure if this is the proper way to do it.
What do the authors of the library think? Did you ever do a begin(...); stop(); begin(...) cycle?
Achim
CC3000 library: stop()
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- adafruit_support_rick
- Posts: 35092
- Joined: Tue Mar 15, 2011 11:42 am
Re: CC3000 library: stop()
Thanks! I'll pass the report along to the library's maintainer.
- tdicola
- Posts: 1074
- Joined: Thu Oct 17, 2013 9:11 pm
Re: CC3000 library: stop()
Hi Heideachim, yep I've also seen the stop (and begin) functions have a few issues with being called multiple times. It's a good bug I'll put on the library to come back and fix, but for now the best thing to do is use the lower level wlan_stop() and wlan_start() functions. These are ultimately what get called and put the CC3000 into its low power mode. You can see how I used these in the low power datalogger guide, along with some other good tips on reducing power consumption. The really big win is if you can completely switch off the CC3000, since it has a small LED that will draw ~8mA even when the chip itself is in a low power mode. Let me know if you have any issues.
-
- Posts: 3
- Joined: Fri May 23, 2014 5:13 pm
Re: CC3000 library: stop()
Tony, the good thing about the stop()-bug is, it fails instantly. A completely different picture is the behaviour of the whole stack (mainly the TI part of it) to completely halt the system when something bad happens. There are just too many places where there is a while-loop waiting for something that might never happen, and this while loop has no timeout-mechanism.
I think this also happend during your measurements, when the connection to the router could not be established - your program hang. That is not a good behaviour of a communication stack. Much better would have been not to transmit this one single value and return with an error message to your application.
Right now, I am going through the stack to eliminate this behaviour. I have got a very good test setup - my lab is on the third floor while the wireless router is in the basement. Signal strength of the CC3000 is only 11%! Thus I get all kind of failures during connecting, DHCP, etc. Lucky me! This is an excellent test for the CC3000 library!
If you or somebody else is interested in those modifications, let me know.
Achim
I think this also happend during your measurements, when the connection to the router could not be established - your program hang. That is not a good behaviour of a communication stack. Much better would have been not to transmit this one single value and return with an error message to your application.
Right now, I am going through the stack to eliminate this behaviour. I have got a very good test setup - my lab is on the third floor while the wireless router is in the basement. Signal strength of the CC3000 is only 11%! Thus I get all kind of failures during connecting, DHCP, etc. Lucky me! This is an excellent test for the CC3000 library!
If you or somebody else is interested in those modifications, let me know.
Achim
- tdicola
- Posts: 1074
- Joined: Thu Oct 17, 2013 9:11 pm
Re: CC3000 library: stop()
Yeah, the TI code does have a lot of busy waiting loops which can cause lockups if the CC3000 gets into a bad state. There's a known issue TI has been investigating with a lot of ARP traffic causing buffers to be lost and eventually locking up the driver code (it gets stuck in a loop waiting for a buffer to be free, which never occurs). TI is working on a new firmware update from what I understand so hopefully some of those issues can be resolved. You're right though there are other places like DHCP, etc. where timeouts would be nice. Would definitely be interested in seeing what changes you make to deal with instability--feel free to comment or send them to the library's home on github. Thanks!
Please be positive and constructive with your questions and comments.