• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 40 subscribers
  • Views 529 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Persistent CC3000 Bugs

Wesley Vrancken
Prodigy 20 points
Other Parts Discussed in Thread: CC3100

I've been trying to get the CC3000 to work at some level of consistency on and off for about a month now. In this time I've read a lot of ( if not an excessively amount of ) complaints about the CC3000. I know what most of the outstanding bugs are and have encountered most of them myself, but I wonder what current workarounds are for some of the existing problems.

My setup consists of a STM32F407 and the CC3000. I've got the latest firmware and host driver ( 1.14 / 1.32 ). I've got a working CC3000 and working ( to some degree ) TCP and UDP communication. I open a TCP socket and write 8 packages of around 600 bytes per second to a NodeJS server I've set up for debugging purposes. Communication is working, but there are random hiccups from time to time.

These are the ones I'm encountering :

  • The closing of the socket can take upwards to 3.6 seconds and might not even close properly on the NodeJS side
  • TCP sends that seem to succeed on the STM32 side but are never captured on the NodeJS server ( rare, but it happens )
  • Buffer starvation, which is described in detail in this thread: https://community.spark.io/t/bug-bounty-kill-the-cyan-flash-of-death/1322/444 and in which, according to the Spark folks, is fixed in a less recent TI firmware update

Working from a single socket for all data, seems to cause the buffer starvation to happen earlier than working with a new socket every second. But then again, working with more sockets increases the risk of incurring the close socket delays, which is quite detrimental to my data flow.

I've tried everything from decreasing my data flow size and frequency to implementing delays after every socket open/write/close. I've made my sending non blocking, but it results in the same full deadlock of the CC3000 after a while of sending. I've also tried implementing the new ARP events into my code so that I wait with sending new TCP requests when an ARP is on its way ( what else are these ARP events good for anyways ? ).


 What are the current workarounds / fixes available for the problems I've mentioned ? I don't care too much for the infrequent dropped package, but that buffer starvation problem is really killing any chance of this turning out to be a functional system.

  • 0
    Intellectual 635 points
    Hi Wesley,

    It sounds like the buffer starvation issues you are running into are somehow different enough from the workaround mentioned in that Spark Core post. We unavoidably land in some kind of deadlock or hangup during periods of high TCP activity while downloading files from a remote server, and we have no workaround other than resetting the module and host driver state.

    I hate to be the one to suggest this and I know it doesn't address any of the issues you've run into, but if you're only a month into this project, have you considered using a module that isn't being dolled up for eternal rest in a casket? While it's somewhat reassuring that a real company like Spark is still putting pressure on TI to solve these reliability issues, I'm sure you're aware of the CC3100/3200 modules being "on the way" to being released "some time in December". Last I saw, there were datasheets and diagrams available for designing around, and dev boards have been available for some time.

    We have switched to an ack.me module since it's immediately available, has a higher-level control scheme, is on a very active development cycle with firmware updates at least once a month, and generally seems to be well-supported. Also, have you looked at the design of the Spark Photon, which pairs an STM32 MCU with a Broadcom radio?

    Sorry in advance for a less-than-satisfying answer.
  • 0 in reply to Vishal Talwar
    Prodigy 20 points
    Hey Vishal

    Thanks for the answer, I pretty much gave up on expecting one. Even though you can't provide any answers, it's gratifying enough to know I'm not alone and that there clearly are problems that just won't go away.

    My current workaround for the buffer starvation is always keeping a buffer open and using non-blocking sends. This doesn't actually stop it from starving, but it does stop the CC3000 from going into unrecoverable deadlock. The buffer starvation doesn't happen at once, but goes into a spiral at a certain point in which with every extra send it will have more trouble clearing up it's buffers. So since I can't powercycle, I reset the CC3000 before it reaches the end of its spiral.

    The missing TCP packets I had were most likely due to sending them out faster than my NodeJS could handle them and me not reacting to it in the right manner.

    I'm already on the lookout for new WiFi modules and those ack.me ones will definitely be taking into consideration.