CC3000 driver hangs

I have the same exact problem. Have not been able to fix it for months since I don't exactly know what causes it. I would be eternally grateful to whoever is able to diagnose and fix this issue.

The cause of the driver hanging is a bug in the firmware, which TI has failed to address and fix for the last 7 months. This issue is also the reason why no commercial products are using the CC3000, despite being in the market for two years now. Sooner or later people who invest their time in integrating the CC3000 into their product run into this issue and are forced to find another WiFi chip.

As far as I can tell this is the most comprehensive thread on the issue, and even though it was started 7 months ago the only workaround that exists is to restart the CC3000 when it hangs:

http://e2e.ti.com/support/wireless_connectivity/f/851/t/293532.aspx?pi267162=1

Thank you Ivor for the response. I have read the thread and it seems that there is no solution for the problem.

Rebooting the device when it hangs is no way to go for us. Our test devices hang around one time per minute.

Is there any statement from TI about this problem? Are they working on a solution? We like to release our product (~ 5000 pieces) in a few months and we can't do this big bug.

I'm having the same problem over here... I have no idea if it is a simple or complex bug to solve, but looks like some other people have been dealing with the same issue.

Just in case it helps, i've ported the host driver to an Atmel SAM3N+Freertos microcontroller.

I don't know if there's a problem with the OS missing some interruptions. I currently don't have a logic analyzer but hope to get one in the next few weeks. Has somebody been able to analyze the behaviour described here: http://e2e.ti.com/support/wireless_connectivity/f/851/t/312391.aspx ?

From what i've been seeing, the code gets stuck waiting for this to happen:

if (tSLInformation.usEventOrDataReceived != 0)

Any help will be appreciated !

I am having the exact same issue.  It hangs up waiting for a reply in the same place.  Mine is nested inside the accept() command in my TCP server program.  

When I strip my server to the basics it works fine.  I.e. accept() + close().  When I add in recv() it works well too.  Then, if I add a send() after the recv() I get the hang up issue nested inside the accept().  I still can't make sense of why this happens.  The send() and recv() functions are supposed to be blocking.

If I add a delay of .1s after the accept(), it prevents hang ups for the full server.  This isn't a solution I'm 100% comfortable with unless it's in the specs.  Still, I'm probably moving forward with this.

Dear TI

It seems that this is a big issue for a lot of people. It makes the CC3000 completly useless. We can't release our product with this bug with the CC3000.
Are you working on fixing this bug? A statement would be nice.

Agreed with previous. TI, we need - and deserve - a response to this. Leaving issues like this unanswered encourages me to turn to other vendors.

Ciarán

I came upon a post here (http://e2e.ti.com/support/wireless_connectivity/f/851/p/305722/1183516.aspx#1183516) which links to some chinese guy who supposedly managed to solve this (I'm not 100% sure he describes this particular hang, but in the second point it seems similar):

http://kuangqi.me/embedded/cc3000-host-driver-porting-guide/

Unfortunately it's in chinese, but google translate seems to do a decent job. Not that I managed to fix it, but it might be helpful for TI to investigate. 

Ti we are still waiting for a statement.

Is there a plan to make the cc3000 usable or shall we look for an other WiFi Chip?

Has anyone tried the chinese solution?

This is a firmware bug and there is no magic solution to it, Chinese or otherwise.

Did anybody managed to get an answer from TI ? I'm afraid they leave us with no support...

I would also like to reconfirm the original poster's finding that the issue is also present in the latest v1.13.

I too have this issue, which is driving me nuts. I can't lauch my product without this fix. And getting to the point now where I will have to look at alternatives like a Wiznet Wiz250 or Microchip RN171. 

I really like this product but if there is no support, or fix available or even a communication/statement from TI, why should we continue to suffer and use this product?

Posting on this forum rarely produces any results. I have seen another approach that works much more effectively for large hierarchical companies like TI.

Basically we can write a grievance e-mail and get as many people as possible to sign it. There are so many issues to address, we will not be short on content. Then we need to send this to the mid-level manager in charge of the CC3000 product. But we will also CC his manager, his manager's manager, etc all the way up to Richard Templeton. But before we can do this we need someone from TI to provide us with the contact information of the manager in charge and everyone up the management chain. Large companies like TI usually have an internal organization chart tool that any employee can look up.

When I worked for Microsoft this actually happened to one of the other teams that I worked very closely with. It was just a half a page e-mail, but it was signed by more than 50 people and it had flawlessly CC'd the managers on the chain all the way to Steve Ballmer. As far as I know Steve never responded, but the lower level managers created the largest fire drill that I have seen in all my time working there.

I know that Dana Mayers is the platform marketing manager for the CC3000 - maybe we can start by contacting her:

http://www.youtube.com/watch?v=10U4NTgkjLs

Please let me know if you guys think this is a good idea to get TI to address at least the most urgent issues.

I think this is an excellent idea. Our whole development stands because of the unusable CC3000. We have already started looking for an alternative.
The CC3000 can be a million selling Chip, but not with that many bugs.
We tried to contact TI in many different ways but all with no luck. They seems to ignore us.

I totally agree with Ivor Sargoytchev. A grievance e-mail will something that they will pay attention to.

I' ve designed a very brief Google Docs Form, so that everyone that had an issue with the CC3000 module can express their opinion. This can also help to write down the email.

Please take a couple of minutes to fill it. After you finish you'll be able to see what othe people have filled.

https://docs.google.com/forms/d/1XmdxqF5-l_GvKDSPTJTgDAp8HfNbh5p_z68smFhtmag/viewform?usp=send_form

Thanks for your cooperation!

• Reply

Posted by Ivor Sargoytchev on Jun 11 2014 05:36 AM

Dear All,

I would like to begin by saying that I am very sorry that no one from TI has responded to this thread. There is absolutely no justification for this and I will not present any excuses.

Since several issues were high-lighted in this tread, I wanted to assure you that we have been looking into the CC3000 issues in the various threads. In several cases, we were able to reproduce the issues and root cause them as CC3000 Firmware bugs. We have published several updates over the last few months and have received positive feedback from customers. Release 1.13 is the Latest release.

However, as mentioned in this thread, there are some issues that are still unresolved. Some of these are unresolved because we are unable to reproduce while others are under actively being analyzed.

We are planning to publish early next week, plans as well as recommendations regarding  CC3000 open issues. 

We appreciate your feedback and patience and I wanted to assure you again that we are listing to all of the concerns and issues being high-lighted in this and various other threads on this forum.

Thanks,

Adnan

Just sent in my description.  Is there a place we can see results without filling out the form again?  

Also, how can everyone be so sure that this isn't user error?  Either way, I think TI could stand to have more support for this device.  Still, we've all seen their demos and can say that the chip CAN work.  Just wanting to get people's opinions.  The language here is pretty harsh and not necessarily constructive.

Adnan,

It finally sounds like TI is taking the right steps to fix this forum and the CC3000 and I do appreciate it.  "We are planning to publish early next week, plans as well as recommendations regarding  CC3000 open issues."  I have been asking for this forever and am very glad to see it being implemented.  All we have ever asked is to know where TI is in the update process(testing bugs, fixing bugs, testing fixes, etc) and what issues they were looking at.  A little transparency never hurts and shouldn't be an issue with a wifi module.

As many others have stated another big issue is dead threads from TIs team.  It just seemed like in the past they would get so far into discussion of an issue and then not respond for a month.  We never knew if they were testing or just gave up on the issue.  Every thread should come to a conclusion even if it has to be,"sorry we have no idea at the moment and we are doing x, y and z to learn more, here is how you can help".

We understand there are issues and have been waiting patiently trying to help(over 9 months for me) and waiting for help.  The best thing TI ever did with this product was do this wiki because without it this product would have been dead months ago.  So please continue to appreciate what your customers have helped you build and lets see it through to the end.

David,

 I still am seeing some issues too after 1.13, but have not yet completed some tasks that may be causing them.  I will comment with details if it seems to be an issue with the CC3000.  One thing I have always had issues with in this module is basically everything is a blocking function in that you must wait for the response to your command before moving on or you will get all messed up.  I do not use the TI driver since I use Atmel mcu to drive CC3000 so I wrote my own and I block anything while I am sending the CC3000 commands.  

For example, if I am doing Accept it kept interrupting things at bad times so now I basically have an Accept_Disable and Enable so it only checks for a connection if the mcu and CC3000 spi is idle(I never disable my SPI, not sure why TI does that).  I have other "lockouts" as I am running a TCP server UDP server and connecting to a TCP server as a client also and need to make sure the CC3000 is only doing one thing at a time.

Think about the fact that there is a single send buffer, if you fill your buffer and get ready to send but are interrupted by say a select to check for data.  That function will fill your send buffer and complete its communications correctly but when it returns to your next function the send buffer is now filled with the select command and the function you were in will fail and possibly piss the CC3000 off depending on what you are doing.  Things like this were leading to some of my issues and keep in mind I am not using TIs software so they may have all this figured out correctly or they may  depend on you to make sure functions don't get interrupted incorrectly.  Just some food for thought.

Basically timing is everything since everything is such low power and single core processing and possibly even single thread in the CC3000.  I have everything basically stable with a few minor hiccups that cause reconnects, but currently I can recover from everything and keep going.  I hope to release my product to limited amount of people at the end of the month after some more testing.  As far as I know the CC3000 has not been stable enough to deploy until now and I may be one of the first if not the first to release with this module, so it is possible to use this module.  Hope this helps in some way.

Thanks,

Chad

I see this issue is still not resolved. It was one of the major reasons I began to take a different path 3 months ago.

Not sure if everyone has seen this yet, but perhaps this is the reason for such poor support, and perhaps this will provide a way forward that will mean a lot less rewriting of code than switching to a different vendor's chip. And of course you still get Smart Config.

The CC3100 BoosterPack and the CC3200 LaunchPad have just been released. And they looks great! But will they have the same issues that plague the CC3000, time will tell.

CC3200-LAUNCHXL - SimpleLink Wi-Fi CC3200 LaunchPad

CC3100BOOST - SimpleLink Wi-Fi CC3100 BoosterPack

CC31XXEMUBOOST - Advanced Emulation BoosterPack for SimpleLink Wi-Fi CC3100 BoosterPack

and

CC31xx & CC32xx Wiki

CC31xx Quick Start

CC32xx QucikStart

Glenn.

I'm glad to hear that someone at TI has finally heard us!

For those of you who were asking about seeing the poll results you can see them by following this link:

https://docs.google.com/forms/d/1XmdxqF5-l_GvKDSPTJTgDAp8HfNbh5p_z68smFhtmag/viewanalytics

Hope to have good news soon...

Why there are people that works fine?

I have the same problem. Never enter to the IF.

while (1)
{
if (tSLInformation.usEventOrDataReceived != 0)
{
pucReceivedData = (tSLInformation.pucReceivedData);

if (*pucReceivedData == HCI_TYPE_EVNT)
{
// Event Received
STREAM_TO_UINT16((char *)pucReceivedData, HCI_EVENT_OPCODE_OFFSET,

We are pleased to announce that TI recently introduced the next generation in embedded Wi-Fi with TI’s SimpleLink™ Wi-Fi^® CC3100 and CC3200.

The newly announced SimpeLink Wi-Fi devices were developed from the ground up to provide new capabilities to the market, namely:

• CC3200, the Industry’s first Internet-on-a-chip™ with an integrated programmable MCU
• QFN package for easy chip on board layout
• Additional Wi-Fi modes & standards including access point mode, 802.11n, WPA2 enterprise & more
• Additional Wi-Fi low power modes including hibernate with faster wake up and connection times & more
• Integrated Internet & security protocols & applications including SSL 3.0, TLS 1.2, Http Server & more
• Flexible Wi-Fi provisioning options including access point mode, WPS2 & more (in addition to SmartConfig ™ mode)

CC3200 and CC3100 offer many additional enhancements over CC3000:

• Integration of additional internet and networking protocols, such as mDNS, TLS/SSL and others, on chip, ensuring enhanced end-to-end stability and robustness in system level use cases
• Robust BSD Socket Interface
• Support for Non-Blocking APIs
• Robustness enhancements to TCP & UDP Data transfers
• Enhanced SmartConfig™ capabilities
• Fixes for CC3000 known issues and limitations

TI recommends CC3200 & CC3100 for all new and existing embedded Wi-Fi & Internet of Things applications.

Products designed with CC3000 can be easily migrated to CC3100 or CC3200:

• Similar Network Processor APIs enable easy migration of CC3000 Customer Applications to CC3100 or CC3200
• CC3100 & CC3200 are provided in an easy-to-layout QFN package, with the Power Amplifier, Switch & DC2DC now integrated on-chip.
• A Wi-Fi & FCC/IC/CE certified TI module solution, including integrated clocks, serial flash and RF filter will also be available soon.
• The CC3100 host driver can be easily ported to any MCU
• The CC3200 peripheral driver APIs are compatible with SDKs for TI Cortex-M4 devices

TI offers extensive resources to help existing CC3000 customers to migrate to the next generation:

• HW Design resources including CC3200 Launchpad and CC3100 Booster Pack with Reference Design files, User’s Guides, Design checklists, Datasheet & Technical Reference Manual
• Software Development Kit (CC3200 SDK & CC3100 SDK) with 40+ MCU Peripheral, WiFi & Internet-on-a-chip sample applications with support for multiple Integrated development environments including CCS & IAR
• Extensive SW documentation including Programmer’s Guides, Doxygen-based API Guides & Host Driver Porting
• PC-based development tools for flashing, configuration of network & software parameters, RF Testing & Evaluation & PC based code development & debugging
• Dedicated & Responsive E2E Forum that is actively monitored in multiple time zones

TI is planning to Release a new  CC3000 Release (v 1.14) in the upcoming month. TI will also publish a comprehensive errata of all known limitation and issues that exist in the CC3000 release as well as the status of these issues in CC32xx & CC31xx.

We would like to thank our customers for their interest in SimpleLink WiFi devices and their valuable feedback which has been a valuable resource in the development of the next generation in embedded Wi-Fi - TI’s SimpleLink™ Wi-Fi^® CC3100 and CC3200.

How is this easy to migrate the CC3000 to these new CC3100 or CC3200, It's a completely different footprint.

This is not easy, this is hard, requiring a redesign of our designs to use these new chips. Re testing and re certification.

So I hope the new module version of these chips is going to be a Drop in replacement. Else you guys really need to remove the easily bit.

Stephen Edwards1 said:

How is this easy to migrate the CC3000 to these new CC3100 or CC3200, It's a completely different footprint.

This is not easy, this is hard, requiring a redesign of our designs to use these new chips. Re testing and re certification.

So I hope the new module version of these chips is going to be a Drop in replacement. Else you guys really need to remove the easily bit.

The CC3100 and the CC3200 are in no way drop-in replacements. The CC3000MOD is a FCC (+ others) certified module, which you can use without worrying about your own certification. The CC3100 and CC3200 are just bare chips. TI will release certified modules for those at a later date, as mentioned in this announcement:

http://newscenter.ti.com/2014-06-16-Add-Wi-Fi-to-anything-with-TIs-Internet-on-a-chip

It says: "TI also provides various kits and software tools, a certified TI module (coming soon), reference designs, sample applications, development documentation..."

Has "TI is planning to Release a new  CC3000 Release (v 1.14) in the upcoming month. TI will also publish a comprehensive errata of all known limitation and issues that exist in the CC3000 release as well as the status of these issues in CC32xx & CC31xx." (as shown in above post, posted JUNE) happened yet? 

Hello TI - is anyone listening ????

What's happening about your statement (in June)  "TI is planning to Release a new  CC3000 Release (v 1.14) in the upcoming month. TI will also publish a comprehensive errata of all known limitation and issues that exist in the CC3000 release as well as the status of these issues in CC32xx & CC31xx."?????

Is there going to be a CC3000 firmware release?

Is there a comprehensive errata anywhere?

The CC3000 may be slated for replacement, but this level of (non)support makes me nervous about using the CC3100 and CC3200 products if the support is no better than this

All,

Yes, we still plan to release a new CC3000 Firmware V 1.14 Release and will publish a list of comprehensive Errata as outline in the original message.

We appologize for the delay in the Release. This is currently target for Release in September.

Adnan

Hi Adnan,

Can you confirm, please, that v1.14 is still on target for release this month (September)?

Will the Errata List be released at the same time, or can we see it now?

We have based a new product on the CC3000 & would like to ship it with the best firmware.

Regards,

Mike

Hi Mike,

My advice to you is not to wait for the latest firmware, unless you are blocked by a firmware bug and you don't have a workaround. The assumption that the latest firmware is the best is valid in most cases in life, but it is a complete fallacy when it comes to TI's CC3000. Case and point: when v1.13 (1.13.7.15.28) firmware came out it did not fix any of the major issues already present, but instead it introduced new ones - the gethostbyname() problem for example.

I am in the same boat as you and I have decided to ship with v1.12 (1.12.7.15.26), which I spent the most time testing with and have workarounds for the all the issues I encountered. I tested briefly with v1.13 (1.13.7.15.28), but then I decided to go back.

Thanks, Ivor.

We've done all our development with 1.13... there were a LOT of issues that had to be solved before we had a robust product that we had confidence in.

I'd certainly like to see v1.14, & even more, the Errata List, before considering moving from v1.13.

We'll probably ship with v1.13, but seeing TI's list would give us a little more confidence that we haven't missed anything.  :-)

Regards,

Mike

Not to alarm anyone who is deploying v1.13 in their products, but there seems to be at least one issue that isn't even on TI's radar, and I don't think it's too esoteric a bug to trigger. Specifically, with any product that uses gethostbyname() and might see a user assign the CC3000 a static IP, there is this issue that other people have also run into:

http://e2e.ti.com/support/wireless_connectivity/f/851/t/370724.aspx

This appears to be a regression, as I'm not experiencing it with v1.11. At this point, I'm not even sure what we're gaining from 1.13. I really hope v1.14 doesn't introduce any new bugs, in addition to ironing out most of the hangs that people are experiencing.

On a more constructive note, I think there is something very interesting to take note of in the aforementioned Chinese blog post for everyone who has ported TI's driver to another MCU - the implementation of SpiPauseSpi and WlanInterruptDisable. I quote a translated version of that page:

"""
If the previous one is a pit, then this one is definitely a pit. SpiPause - SpiResume and WlanInterruptDisable -WlanInterruptEnable these two groups of interrupt control functions are CC3000 entire drive porting the most tricky part.

....
WlanInterruptDisable role is closed IO port external interrupt, which is the falling edge of IRQ interrupts. After the close, IRQ interrupts the falling edge will be discarded , calling WlanInterruptEnable , it will re-enable interrupts, then place on the external interrupt and IO can respond again. And during interrupts are disabled, the occurrence of interrupts are discarded and never respond.This function is generally written right.

SpiPauseSpi functions are temporarily suspend IO port external interrupt, that is, the falling edge of IRQ interrupts, if SpiPauseSpiafter the call, IRQ line and then a falling edge, the interrupt will always keep Pending state, temporarily interrupt service routine is not called, the interrupt must calling SpiResumeSpi be re response is not to be discarded. Here, many, many, many people are, wrong. . .

"""

The CC3000 Host Driver Porting Guide doesn't spend any time on these two functions, and I have to agree that correctly implementing the intended behavior may be at the crux of the hangs we are seeing. Just look at the comment above one place WlanInterruptDisable() is called:

// We need to prevent here race that can occur in case 2 back to back packets are sent to the
// device, so the state will move to IDLE and once again to not IDLE due to IRQ
//
tSLInformation.WlanInterruptDisable();

I suppose the best thing would be to go back to an official reference driver and see how TI implements these functions for their own MCUs. The problem is that one has to deduce the API from the implementation, which is completely backwards from how it should be. If TI had spent 15 minutes extending the porting guide with a clear explanation of what a "pause" and "disable" really entails, we wouldn't have to understand the intricacies of the interrupt system on the MSP430 or whatever reference driver we use as the basis.

If we assume there is some conceptual difference between pausing and disabling (as the reference driver suggests), then what exactly is that difference? In our code they are one and the same, and we have managed to avoid most hangs by hacking up these functions to do soft interrupt disabling - that is, interrupts are ALWAYS pending while paused/disabled.

Hi Adnan

Can you please update us on the V 1.14 Release? When we can expect it to be released

Thanks

Arun

Adnan said:

All,

Yes, we still plan to release a new CC3000 Firmware V 1.14 Release and will publish a list of comprehensive Errata as outline in the original message.

We appologize for the delay in the Release. This is currently target for Release in September.

Adnan

Dear TI,

Have you heard the fable of the boy who cried "wolf"? If you haven't, I promise you - it is really good. You can tell it to your kids to teach them some ethics.

Hi TI

We seriously need this new firmware, working, yesterday.

Our customer is getting very irritated and is loosing money every day you don't supply what you have promised for many weeks/months now.

This is a high volume product  series (>10k pcs/Year) and it's probably not the only sale you stand to loose if you don't get your act together. We're considering using the new CC3100 for some units in the series but to be honest that is looking less and less interesting having spent more than 6 months trying to duck various bugs in your module. Right now a cheap module (http://www.aliexpress.com/snapshot/6290638648.html)  
from china is looking more interesting by the minute even though it's a big change for us and will require certifications.

Do yourself a favour and release the firmware, and you might still be able to save some of your WiFi chip/module customers.

Jimmy

Jimmy,

I am not aware of the issues you are facing, but I too had developed a product with the CC3000 and had a few issues. However I moved everything over to the CC3100 and could not be happier.

If you are using the Tiva C and CC3000, then migrating code to the Tiva C and CC3100 should be a relatively straight forward task....it only took me a few days.

Migrating also offers you access to many additional features that are bound to benefit any product. Here are a few:-

• 802.11n Support.
• Connection with Access Point, Station and Wifi Direct modes.
• Provisioning via Access Point mode and HTTP web server, Smart Config or WPS.
• A HTTP Web Server for configuration and also for creating a web app.
• mDNS that works perfectly.
• External serial flash, so you can store config files, data, html pages, certificates etc.

Glenn.

Hi Glenn

Surely we could change module in some of the upcoming products, our main problem right now is the first product in the product line that has been in development for months and which first batch of units (1000 units) is being produced currently in China. Also the EMC, LVD and other certifications would have to be redone.
 Also we have the problem that the new cc3100 modules are bigger than the CC3000 modules and this product has been shrunk to the extreme so there really isn't room for it.

So I'm sure you can understand mine/our frustration over being, multiple times, promised a new bug fixed FW. from TI. Not exactly confidence inspiring...

Jimmy

I can certainly understand your frustration.

All I can do is refer to a post I made in June on this thread - http://e2e.ti.com/support/wireless_connectivity/f/851/p/345205/1216801.aspx#1216801

And let you know that time has shown that things are very different with the CC3100/CC3200, it is stable, all main features work without issue.....basically it is production ready.

Glenn.

Hi Glenn,

I would love nothing more than to stop flogging this dead horse, but I'm not aware of the CC3100 modular (EMC-certified) equivalents to the CC3000MOD being available yet? 

In terms of the APIs or programming paradigm, did you encounter any hitches when porting to the CC3100? We are just about to begin investigating with a development kit, but we weren't sure how much of a drop-in replacement it would be, at least firmware-wise.

Thanks for sharing!

Vishal Talwar said:

In terms of the APIs or programming paradigm, did you encounter any hitches when porting to the CC3100?

No hitches, the only issues are adding all the extra functionality, as you have many more features and options with the CC3100. So in that respect you will likely have some extra work, as you are going to want to say, add some html control options to the internal web server, or perhaps you will want to provide the ability for the user to connect directly or to a WIfi Router....all these extra features will require extra code.

Glenn.

Dear Ivor, Arun, Jimmy, Glenn, Vishal,

CC3000 V1.14 is released, which was requested for quite some time now. I am not at all an expert in this subject & from Sales team. But for benefit of everyone thought of sharing this.

 http://processors.wiki.ti.com/index.php/CC3000_Release_Notes#Version_1.14 

Hope this helps a bit alteast.

Rohith