Teensy 3+ and Adafruit CC3000, verify new firmware?

Status
Not open for further replies.
T

tdicola

Member
Hey all, there's a new 1.12 version of the CC3000 firmware and driver code available from TI and I'm curious if any Teensy 3 folks want to help verify the updated firmware. I've integrated the changes TI made in the 1.12 driver code into a fork of the Adafruit CC3000 library, you can check it out here: https://github.com/tdicola/Adafruit_CC3000_Library/tree/cc3k_v1_12 The release notes for TI's firmware are here too if you're curious: http://processors.wiki.ti.com/index.php/CC3000_Release_Notes

I've loaded the updated firmware on my CC3000 and tested it with the updated library on my Arduino Uno. There aren't any issues I've run into but it would be good to get someone with a Teensy to try it too.

As far as loading the new firmware on the CC3000, it's not pretty but the attached sketch and file work on an Uno and should work on a Teensy. From what I understand you might need to get an older version of the CC3000 library to use with this updater sketch (apparently a version from September works, trying syncing the Adafruit CC3000 repo and then checking out this older version https://github.com/adafruit/Adafruit_CC3000_Library/commit/f358fa5bba7cba5de0ad046bdfdf4fb2b0417b91 by executing 'git checkout f358fa5bba7cba5de0ad046bdfdf4fb2b0417b91'). I'm not totally sure you can downgrade the firmware later, so FYI be careful if you aren't sure and don't want to live on the bleeding edge. :)

View attachment driverpatch_1_12.ino

View attachment driverpat.h

(might need to rename that driverpat.h to driverpatchinc.h, for some reason the forum is changing the name)

After loading the new firmware, grab the fork of the CC3000 library above and use it to run some of the examples or other CC3000 code. Let me know if you run into issues. Thanks!
 
Last edited:
I will give it a whirl, thanks. One thing that I had seen causing trouble for the Teensy3.1 in ccspi isn't changed in the version - we discussed that issue on github before. I tried running the firmware updater before and it didn't work, hope this time it does!
 
Well the last thing my CC3000+Teensy3.1 said was "Write params" and then nothing. It is a bit scrambled now but I can still talk to it, will try more later. Anyone else get it to reflash from the Teensy3.1?

OOPS: Never mind it flashed properly with the right version of the Adafruit Library. Had to put back a fake Mac ID after that unfortunately...
 
Last edited:
I don't find the new version improved for my ChatServer-based Teensy3.1 attempt at an application. It crashes the same without adding time delays to make it survive. Also noticed the overly sticky DNS bug still exists as well. Not sure if it is a new bug or just some debugging code but this version spews some non-ascii stuff to the telnet client on first connect, I had to filter it out in the sketch as the telnet client was having a nasty response!
 
teachop said:
I don't find the new version improved for my ChatServer-based Teensy3.1 attempt at an application. It crashes the same without adding time delays to make it survive. Also noticed the overly sticky DNS bug still exists as well. Not sure if it is a new bug or just some debugging code but this version spews some non-ascii stuff to the telnet client on first connect, I had to filter it out in the sketch as the telnet client was having a nasty response!
Click to expand...

Yeah from the release notes TI made unfortunately I didn't see any mention of bug fixes with buffer exhaustion or other known issues. However there is some news from this thread SparkCore has about CC3000 issues--it sounds like from another firmware update to fix bugs is coming soon: https://community.spark.io/t/bug-bounty-kill-the-cyan-flash-of-death/1322/462 When it's available I'll try to integrate it to see if it improves stability.

That's odd you see characters written from telnet--do you see similar behavior with the echoserver or chatserver examples?
 
teachop said:
Also noticed the overly sticky DNS bug still exists as well.
Click to expand...
What is this "overly sticky DNS bug" in detail ?

The reason for my question is that I initially bought the Adafruit CC3000 Breakout board in order to implement Apples Bonjour/ZeroConf. Iv'e replaced all direct calls to the W5100/W5200 chip in the existing library with (EhernetUDP) UDP calls making it more or less hardware independent and was hoping to be able to get this working on the CC3000, but that would require functioning mDNS support. I've read a couple of threads on the Ti forums that make it pretty clear theta in at least earlier firmware versions this did not work or rather at a very rudimentary and incomplete level.
 
Headroom said:
What is this "overly sticky DNS bug" in detail ?

The reason for my question is that I initially bought the Adafruit CC3000 Breakout board in order to implement Apples Bonjour/ZeroConf. Iv'e replaced all direct calls to the W5100/W5200 chip in the existing library with (EhernetUDP) UDP calls making it more or less hardware independent and was hoping to be able to get this working on the CC3000, but that would require functioning mDNS support. I've read a couple of threads on the Ti forums that make it pretty clear theta in at least earlier firmware versions this did not work or rather at a very rudimentary and incomplete level.
Click to expand...

Do you want to resolve mDNS names so the device can look up other devices, or do you want the device to advertise an mDNS name so it can be found easily? For resolving mDNS names unfortunately you'll have to do it yourself as TI doesn't provide any functions. If you want to advertise mDNS there's super basic support with the mdnsAdvertiser function (here http://software-dl.ti.com/ecs/simpl...__api.html#ga8dabc4994092267cdcaebba245c7f482 ). This firmware update actually fixed a bug where TI's advertiser always advertised the name 'target.local' instead of the name that was provided to the function, so the the mDNS advertisement is now somewhat useful. However that advertiser function doesn't actually listen for mDNS requests--calling it just blasts out the mDNS name & IP to everyone on the network. So to use it you would need to either keep calling the advertiser function in a loop, or do your own listening and respond with it. Continually blasting out the mDNS resolution in a loop isn't really what the mDNS spec says you should do though. You really want a listener to wait for an mDNS query and respond appropriately.

All that said, you might check out this library I made: https://github.com/adafruit/CC3000_MDNS/tree/refactor_simplify This is a simple mDNS responder that listens for mDNS queries and responds to them with the CC3000's IP address. It won't give you the full Bonjour/ZeroConf stack, but is good enough to find the CC3000 by mDNS like 'arduino.local'.

teachop, hrm that's odd that you see the issue with the ChatServer example. I can't repro the same issue with a normal Arduino unfortunately. Just to rule out anything funky with using port 23, if you change the example so LISTEN_PORT is something like 5000 and telnet to that do you still see the issue? Also is it only sending characters when the first client connects, when a second client connects, or when any client connects?
 
Thanks for the detailed answer!

It seems like the only real mDNS functionality the CC3000 offers is link local name resolution that is really just a very rudimentary mDNS support.
The Arduino EthernetBonjour library offers full support, meaning link local address resolution. e.g. arduino.local, service advertising/registering and service discovery. Teensy can browse the network for services, e.g. _http._tcp to find local, advertised web sites. Using the library the Teensy also can register such services so they can be discovered either by other Teensys on the network or other devices.

My practical example are my LED lighting systems that employ a Teensy3<->WIZ820io<->TP-Lnk TL WR703n WiFi Pocket router. The Lamp registers an _osc._udp service. This service is then discovered by TouchOSC on the iPhone, or iPad so no network settings have to be configured. I am hoping to be able to replace the WIZ820io <-> router combo with something more elegant and less bulky. If the CC3000 would really possess the mDNS support initially advertised by TI that would be possible, but as I understand it, the service the CC3000 advertises is not discoverable and it's implementation is only for the initial setup and connection to an AP.

I am wondering whether that is still the case ?
 
tdicola said:
is it only sending characters when the first client connects, when a second client connects, or when any client connects?
Click to expand...
I can say for sure if I drop the connection and reconnect, the string of non-ascii stuff is sent again.
Here is the stuff: F7 F3 25 F7 F5 03 F7 F3 10 F7 F3 17 F7 F3 20 F7 F3 21 F7 F3 22 F7 F3 27 F7 F5 05

(just to recap, this started after the firmware + library upgrade)
 
teachop said:
I can say for sure if I drop the connection and reconnect, the string of non-ascii stuff is sent again.
Here is the stuff: F7 F3 25 F7 F5 03 F7 F3 10 F7 F3 17 F7 F3 20 F7 F3 21 F7 F3 22 F7 F3 27 F7 F5 05

(just to recap, this started after the firmware + library upgrade)
Click to expand...

So I took my Teensy 3.0 off an old project to try reproing the issue, and both the ChatServer and EchoServer examples seem to work without issues on the v1.11.1 and v1.12 firmware (using both the current and this updated library). I'm using the command line telnet client built in to MacOS X to connect.

One thing I did have to do was add a small 10 millisecond delay after the character is written to the CC3k in both examples. I noticed there was some instability without it, where the whole sketch could lock up. I have a feeling this is hitting the buffer exhaustion problem that's a known issue with TI's current firmware--the problem is when writes happen too fast the CC3k will leak buffers and eventually exhaust them and stop responding. Since the Teensy is much faster than the stock Arduino it's probably easier to hit this race condition. Adding a small delay after the client write seems to fix this and make it more stable.

The other thing I noticed is that if you try to power the CC3000 from the Teensy's 3.3V output, there probably isn't enough current and you might see some instability. On the v1.11.1 firmware it seemed to work, but once I upgraded to v1.12 I noticed the CC3k light would go dim and the Teensy would stop responding. Once I reconfigured things so the CC3k was powered by an external supply (5V into its VIN pin) everything seemed to work great. Looking at the Teensy 3 instructions/pinout it seems the 3.3V output is only rated for 100mA, which is much lower than the ~200mA the CC3k can pull. Are you by chance powering your CC3k from the Teensy 3.3V output? If so, can you try powering it from an external source?

Also I'm curious, what telnet client are you using to connect to the device? I'm curious if the client has any impact on the garbage characters you see. Odd that I can't repro the issue though.
 
Yes the 10mSec delay is still required on Teensy3.1 to keep things from locking up. That was reported in my issue discussions with you and others on github that got closed down for being teensy3.1 related. It has been confirmed in discussions here by others as well. I had traced that down and found where it locked up in the code at that time. You asked me to do a test concerning buffer issues, and results indicated it wasn't the same problem, although I saw that one as well.

I have never tried using the 3.3V power from the Teensy3.1. I have my teensy3.1 + CC3000 protoboard set up to separate Teensy and CC3000 power, to allow connecting to the USB hub power or to an external supply with commons tied together for the WiFi power, and there was no difference in any of this.

I didn't see that string of stuff until after updating the firmware and the library, and was surprised when I found it wasn't random junk but rather always the same sequence.

I am using "telnet 192.168.1.xxx" from a fully updated Mac command line. If you think that is related I can try telnet from my Linux machine.
 
tdicola said:
Also I'm curious, what telnet client are you using to connect to the device? I'm curious if the client has any impact on the garbage characters you see.
Click to expand...
I was able to test from telnet on an up-to-date Xubuntu machine and the "stuff" is the same sort, but the values differ a bit:
F7 F5 03 F7 F3 10 F7 F3 17 F7 F3 20 F7 F3 21 F7 F3 22 F7 F3 27 F7 F5 05 F7 F3 23
 
View attachment driverpat.hView attachment driverpatch.ino
teachop said:
I was able to test from telnet on an up-to-date Xubuntu machine and the "stuff" is the same sort, but the values differ a bit:
F7 F5 03 F7 F3 10 F7 F3 17 F7 F3 20 F7 F3 21 F7 F3 22 F7 F3 27 F7 F5 05 F7 F3 23
Click to expand...

Thanks for checking--wow that's really odd. Do you want to try downgrading to the v1.11.1 firmware to see if the behavior is normal again? Here's what I used to downgrade my v1.12 to v.1.11.1 firmware in the attached (you can use the most recent CC3000 library to run this updater, the bug with the previous one not working on recent firmware was fixed).

View attachment 1860

View attachment 1861

Yeah the testing in the github issue was to see if putting the library into a non-blocking write mode would help any of the issues. The problem we were running into with the normal blocking write behavior is that if writes come in quickly and the CC3000 doesn't have any free internal buffers (or has leaked them somehow), it will block indefinitely. Switching to non-blocking prevents this, but can start dropping data if delays aren't added after writes. I have a feeling a lot of instability stems from the race condition or issues internal to the cc3000 which cause it to leak these buffers. With the Teensy being faster it's probably easier to hit races like this. I've heard from SparkCore's investigation TI is close to having another updated firmware that might hopefully fix some of these internal issues.

Are there any other folks with a Teensy 3/3.1 and CC3000 that want to try the v1.12 firmware and updated library? I'm curious to get anyone else to try it to see if there are similar issues with the server behavior.
 
tdicola said:
wow that's really odd. Do you want to try downgrading to the v1.11.1 firmware to see if the behavior is normal again?
Click to expand...
That was a good idea to test, it is NOT normal again. The version says "Firmware V. : 1.19" post downgrade. After the downgrade it still prints that stuff, not what I expected.

Maybe it is battle damage in the module from the failed upgrade incident that wiped out my MACID.
 
teachop said:
Firmware V. : 1.19 ... still prints that stuff, not what I expected
Click to expand...
Also tried resetting the driver library repo back to "Merge pull request #55 from tdicola/SPI_clock_fix" which is where I think it was before, and it still sends the stuff.
 
teachop said:
Also tried resetting the driver library repo back to "Merge pull request #55 from tdicola/SPI_clock_fix" which is where I think it was before, and it still sends the stuff.
Click to expand...

Ah, I saw the same issue with the mac address getting corrupted/dropped. To fix it, open the buildtest example and uncomment these lines:

uint8_t macAddress[6] = { 0x08, 0x00, 0x28, 0x01, 0x79, 0xB7 };
if (!cc3000.setMacAddress(macAddress))
{
Serial.println(F("Failed trying to update the MAC address"));
while(1);
}

You can have it set the mac to any value with that--give it a shot just to make sure it fixes the mac address. V1.19 is what you want to see too (annoyingly there are two version numbers, v1.11.1 reads as v1.19 and v1.12 reads as v1.26). Just to rule out any mac address weirdness, try updating the mac and let's see if you still see characters sent.
 
tdicola said:
To fix it
Click to expand...
I fixed the MACID when it happened by generating a new one and pulling a trick similar to what you used (msg #3 above). So the MACID isn't a problem, but maybe some other setting was damaged in the module. ?
 
Last edited:
teachop said:
I fixed the MACID when it happened by generating a new one and pulling a trick similar to what you used (msg #3 above). So the MACID isn't a problem, but maybe some other setting was damaged in the module. ?
Click to expand...

Hrm the driver patch code is a little tough to follow, but it looks like the basic thing it does is save the module's NVMEM settings into memory (128 bytes total) and then to EEPROM if the settings were successfully read. If it couldn't read them (after making 3 attempts) it will default to load the default settings from the included header (from the cRMdefaultParams variable). It will then rewrite the FAT index that points to each setting file, and finally rewrite the settings themselves--either from what was successfully read earlier, or from the defaults. After updating the settings it will go on to update the firmware and patches.

When you run the upgrade to v1.12 do you see the message "Load default params" or "Load EEPROM params" printed? If it's the former, then it fell back and is using what was included in the header. If the latter, it's using what was already on the chip. I wonder if forcing it to use the defaults included in the header would help (presumably these are good values since they're coming from what TI ships). Try updating this bit of the code in the firmware updater sketch:

if (counter == 3) {
Serial.println(F("\n\rLoad default params"));
pRMParams = (uint8_t*)cRMdefaultParams;
} ...

So that it always goes into that branch, i.e. something like:

if (1) {
...
}

Let it rewrite the firmware using those defaults and lets see if it puts everything back into the default state.
 
tdicola said:
Let it rewrite the firmware using those defaults and lets see if it puts everything back into the default state.
Click to expand...
The same sort of non-ASCII stuff is output on connect after doing those steps. Who knows. The lock-ups bother me a lot more than this issue, so I hope TI and/or Adafruit and/or PJRC and/or SparkCore are able to sort that out soon. Thanks for helping!
 
Status
Not open for further replies.
Back
Top