CC3000 with Teensy3.1

Status
Not open for further replies.

teachop

Well-known member
Is there anyone using the Adafruit CC3000 breakout with Teensy3.1? My application is based on the Adafruit example ChatServer. The experience is it will work stable with a 10mSec delay inserted into the loop() function. Otherwise it locks up fairly quickly. I have gathered some data with logic analyzer and was looking for help on Adafruit. They are not interested in helping since it isn't classic AVR Arduino. Any interest here in working on this combination? Thanks.
 
I have some data on the event in the form of logic analyzer traces, and also a following of the path of the code to where it is locked up. I also believe there are at least two problems.

One thing of interest is swapping two lines relating to how chip select is dropped and interrupts enabled in the spi write routine makes the problem much harder to reproduce. For whatever reason. One possibility is it "fixes" one of multiple issues. Another is it changes the timing mix. Or it is just random, but it seems to make a difference. Anyone else interested in working on this issue to get CC3000 and Teensy3.1 combination working? Here are the swapped lines in ccspi.cpp that I was speaking about. It is at line 355 in SpiWrite().

Code:
    /* Assert the CS line and wait till SSI IRQ line is active and then initialize write operation */
    //CC3000_ASSERT_CS;

    /* Re-enable IRQ - if it was not disabled - this is not a problem... */
    tSLInformation.WlanInterruptEnable();
    CC3000_ASSERT_CS;

As I said this reduces the ability to lock it up, but doesn't eliminate it. What it does do is prevents the little fix-up conditional following it from being activated, from what I have seen in this ChatServer-based application. Prior to the change it was executing on the Teensy3.1 a lot. I also tried for comparison on AVR to see if the fix-up conditional is activated (stock, no code changes) and it is not in my ChatServer tests, for what it is worth.
 
You'd likely get better responses if you post your complete code, or if it is too big a short example that reproduces the behavior. Actually the latter is likely preferred.

This would also allow people that have A CC3000 to run the code and see if it can be reproduced at their end as well. I have one here but have not had a chance yet to work with it.
 
The code should be stock ChatServer example. There is no need to do anything to it, the issue can be reproduced (at least on my wifi here!) just as it comes in the Adafruit library by building the example, telnet-ing in, and starting to type away. The file referenced above is part of the Adafruit library, basically the SPI driver.
 
teachop, i just put the 3.1 and cc3000 back together on the breadboard, and yes, locks up without the delay(10); at the start of the loop, but seems to function properly after including that delay(), I had a telnet session running using mac terminal and put an additional line in the loop to write an additional response to the terminal window just be sure, and the session did not crash. I have the cc3000 pins as 2 and 9 rather than the 3 and 5 in the standard sketch, but this should not make a difference. How long did you have to wait before the session crashed?
 
Last edited:
That is the one mortonkoph, thanks for testing. I would think the pins don't matter on the ARM. If you want to try the change to ccspi.cpp it would be interesting to find if the lock ups become much harder to reproduce. I swapped the dropping of CS on the CC3000 and the re-enabling of IRQs in SpiWrite() as can be seen above and saw a difference. With the change, the IRQ code handles the back-to-back requests which was the original intent I think. Unfortunately it is still going to crash in minutes based on my experience. (remember to take the delay(10) back out of the loop for testing!)

If you do change the library like that, you probably know it is required to get out of Arduino and back in for the Teensy3.1 stuff to re-build libraries (anybody know a trick to avoid that?) unlike the regular AVR stuff.

The TI people are chasing lost-buffer problems that I have seen too (probably has nothing to do with ARM vs AVR). I put in a pin wiggle that proved the buffer exhaustion problem was indeed happening some of the time. It is a different problem from what I can tell - multiple things going on make it complicated. For some reason though when I used a straight Arduino I had no lock up at all. Probably timing related.
 
teashop, re lost buffer content: I was using the CC3000 to receive UDP packets in an artnet wrapper (carrying led info for octows2811 array) and did not have any lost packets when testing using a print.serial to printout packet number and sequence. This was receive only and did not use any acknowledge. BUT…. It s all new to me as you can tell. I will test the simple setup of chatting to see how long it takes before crashing.
 
Ok thanks. I don't know what it takes to trigger the buffer problem but have seen it myself. They told me where to put the pin wiggle and I did catch it. It is a different issue and smarter minds than me are working on it!

I have is not been able to find a really proper datasheet for the CC3000. There is stuff in the TI wiki that is incomplete, and the datasheet is mostly for mechanical and circuit design. For the software side it is sifting through the library and decoding stuff with the analyzer (that doesn't seem to perfectly match the wiki information).
 
So, I did a test to see if there was some timeout or crash related to not communicating with the CC3000, the terminal printout is below. Its not very scientific, all I did was wait for 30sec, 1min, 2min, 3min, 4min, and 5min to see if i could still get a response after waiting. It all worked well with a total chat time of 14mins with no issues. I did notice that there was a delay in response after no comms for 2mins, I assume it was the sleep/power saving function kicking in on the cc3000. I assume that you have checked the inactivity timeout, and that you are on the latest TI software release. Other than this check, I think that I can't really help much, but hey, at least you know that the basic sketch should work (with the delay(10)).

telnet> telnet 192.168.1.10 23
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
12.21
12.21
12.22
12.22
12.22 again
12.22 again
12.23
12.23
another 12.23
another 12.23
12.24
12.24
still 12.24
still 12.24
its 12.25
its 12.25
12.25 still
12.25 still
12.26
12.26
wait longer
wait longer
12.28
12.28
wait 3mins?
wait 3mins?
12.31
12.31
wait 4mins?
wait 4mins?
12.35
12.35
ending
ending
 
Awesome, thank you for the time and efforts. My ultimate goal is to get this combination working without the delay(10) as there is something "in there" not quite right..

By the way my project is also supposed to be driving neopixels once I get past this debugging (which is more interesting at the moment anyway).
 
one last thing from me, (and feel free to frown at me!) are you using an additional power source for the cc3000, as it draws a chunk of mA.
 
Yes good question. Grounds are tied together and the CC3000 has its own properly sized power source. Since you saw the same ChatServer lock-ups without the delay(10) I am more confident that it isn't something particular to my wiring or router or etc. Thanks for helping!
 
Hi,
Yeah I'm also getting this issue whenever putting the CC3000 into any form of server mode. Trying to build a simple HTTP server and can often get it to serve pages if I put in a delay in the main loop.

Looking at the way the library is implemented, I can see that the Library, polls the SPI bus in every loop, instead of relying on the IRQ request, so it's good to have a pointer to some code that maybe suspect. But I think I tried this and found that it would service one connection and then any new connections would not get seen.

What was rely strange was the fact that if you setup a ping to the CC3000, Prior to any connections the ping would return in 30ms, however after any subsequent connections, the ping would slow down to 400ms, then 2 seconds then fail completely.

I was toying with the idea of throwing out the Adafruit library and looking at implementing this guys library instead, see if it fairs any better. https://code.google.com/p/cc3000-non-blocking-lib/

But before I do that I want to exhaust all my avenues. So it's good that someone else is having the same issue, (Well not good for you, I mean good that we have a common issue (Not that that is good either :p ))
 
The bug you describe I have caught as well, and it is (seemingly) a different bug from the one I was originally tracking. But I have analyzer traces, several cases, where it fails and begins responding in at 1 second intervals, and then fails completely. Since there are multiple problems, I think it is very hard to track down.

I went off to write a Teensy 3.1 CAN driver for a while, so as to take a break on this.

Please keep us posted on how the alternate library works out.
 
Shoot. I think your right about the several problems.

And now I've got side tracked to building a Pick and place machine instead, in anticipation that someone else would fix my CC3000 problems.

Oh well, back to looking at it again I suppose.
 
Oh well, back to looking at it again I suppose.
I won't be giving up on it, am just taking a break. I am hoping some of the experts / stakeholders will get involved since we have data and a way to reproduce the issues.
 
Right, I think I have a viable solution.

Throw out the Adafruit library, put in the Energia SimpleLinkWifi library (Arduino clone for the TI Launchpad), replace all the Energia.h in the library with Arduino.h. Load up the SimpleWebserver Example. Add some defines for four io pins, And hay presto. One Webserver. Up and running and NOT crashing. (I Hope).

I'll try and stress test it during the day, but it's looking very promising!
 
Frustrating. Thanks for keeping on and us up to date, Teensy+CC3000 is going to be great when it gets working!

A little info: I read over at Adafruit that they have a new software version from TI and are working to integrate that in their code. While Teensy3.1 isn't officially supported (they told me that) I remain hopeful that TI is progressing. When this version hits from Adafruit (or if TI decides to release complete documentation) I will be back on the CC3000.

[For now I keep cranking on CAN for Teensy3.1, learning XCore / XC, etc]
 
New software and new Firmware already integrated in this version I have :p

I was getting desperate, pluging in, merging etc. Hoping the new firmware would fix it. But alas no.

Any who, back to my day job, Hopefully I can get some inspiration.
 
Well I think I've got a stable Webserver now. Issue was that the println or write was stuck in a loop, so added a get out clause (need to investigate why it lost a SPI message).

Been requesting pages from the server all day now and it seems stable.

So now I need to make more complex requests and see how things fair. But it's looking good.
 
Status
Not open for further replies.
Back
Top