CC3000 Patch not Sticking? [Issue Redirected]

Been a while since I made a topic, things have been going pretty smooth so far. But seems a similar problem I had in the past is resurfacing.

I’ve applied the CC3000 patch to all my devices to fix :

  1. The cyan flash of pain which usually was associated with a device constantly having a “connection fail” using TCP client. Along with this, transmissions would be slow and after 2-5 successful transmissions series of connection fails would occur as described above.
  2. The hard fault of pain this was happening when using TCP client as well during regular actons, nothing to crazy happens.

So the first time I applied the patch that fixed 1. and 2. but now for some reason it seems that most of my devices are experiencing the same problem. Is it possible that after some amount of time, or even after a certain of re-flashes to a device that the patch no long exists on the device?

Is re-flashing the CC3000 patch a common occurence after re-flashing it already once? If so is there a way to make it “stick” better?

As always any direction or insight is much appreciated, thanks for your time :slight_smile:

UPDATE: Confirming that my device had patch 1.3.2 on it, and re-flashing my preferred version of 1.2.9 seems to have fixed the issue. I don’t remember having 1.3.2 on it beforehand :frowning:

There is a problem with DNS that on the TI part that I know for sure re-patching will at least temporarily fix. I am sure that the code on the TI part is not really changing, but resetting some internal state inside the TI part that goes along with patching is known to fix a particular DNS problem.

Other than that, I have not heard of any problems that require patching the TI part more than once.

Just like all other flash devices, the storage inside that TI part that gets patched has an endurance rating or maximum number of write cycles, so you don’t want to re-patch it if you don’t need to.

Thanks for the speedy reply @bko!

Hmm it didn’t seem like I had a DNS issue. I used the DNS Test Tool from mtnscott here to check the DNS and it was set to what was expected.

But flashing the CC3000 V1.2.9 patch over the V1.3.2 that was on my device seems to have fixed the issues I outlined. I’m hoping it holds, it has been for a little while now. But I mean is it possible for it to revert back to the state I described in 1. and 2. ?

Further, if you don’t mind explaining for me @bko what are the main reasons that a device would be hard faulting (with regards to TCP, because that’s what seems to be HF’ing my device)

Generally speaking a hard fault is when the code follows a pointer to something but that pointer doesn’t point to where it should. The code is trying to refer to memory that the processor knows it shouldn’t, like page zero.

Walking off the end of an array such as depending on a char array to have a terminating zero but it has none or returning a pointer to something on the stack that is de-allocated when your function returns, writing past the end of memory allocated for a particular array, parsing something to find its length but the data is screwed up and the length is wrong are all common ways to get a hard fault.

It can be very hard to tell what causes a hard fault because the creation of the problem and the discovery of the problem are often very far apart in the code and in time.

The cure for hard faults is defensive programming.

2 Likes

Taking your advice to heart, and will be combing through things, thank you very much for the crash course @bko !

1,3.2 is available but the host driver code has not been updated so that might have caused the issue :slight_smile:

Hmm, is it being updated or is probably not a big deal with Photon and such coming up?

I would (personally) love to see some updates to CC3000 as long as they are core users but i cannot speak for the Spark team. :wink:

@UST, the firmware updates to work with the v1.3.2 udpates may be in the new HAL branch but @mdma would need to verify that. The Photon uses different WiFi hardware so this only applies to the Core.

This is true and I’m on the same page as you it’ll be some time before people switch completely over to the Photon

So there are already workings to make the V1.3.2 deep update function better? This would be good news indeed!

The patches seem to be fine . . . after thorough testing the issue seemed to be something else entirely.

I always knew having too many Serial.print() statements made a Core using TCP/HTTP disconnect from the Cloud and in most cases eventually hard fault.

But since my last reply to this thread, I reduced the number of print statements to just ONE, which was “200” so that I knew my Core made a successful transmission. But I was still experiencing all my original issues that I described in the OP, especially the slow transmissions.

Since taking away ALL my print statements, I have yet to experience a single one of the OP issues. I’m making fast transmissions and have been running consistently for 48 hours, with confirmed data showing that I have not hard faulted since this change.

Wanted to post this so that I can mark this ‘Solved’ or rather ‘Not The Issue’ , should I make a separate thread asking why eliminating all Serial.print statements have made such a difference? Or can we just continue that here?

Cheers :slight_smile:

1 Like