Spark Core Died?

Not to my knowledge. Of course, there is all that code in the ported SD card library, that is the messiest code I don’t know well at all…the printer library was arduino ported but much less complicated. Any tips on how to debug this?

From the video and the description it seems that the Core is constantly resetting (white-green-cyan-red). This is typically caused by a watch dog reset. The Core is basically hard faulting somewhere.

Now that you have figured your way out of it, how is the Core breathing cyan without a WiFi connection?

Is it possible to take a look at your code?

Thanks!

Yes, the ‘dark death’ is RGD LED dim (off), and D7 slightly on.

As far as the 1 minute death, it is more like a 1 minute coma.
Update, it appears that at a minute when everything ‘stops’, there are occasions where if I continue to wait, the last command or items being processed will get spit out (it’ll finish printing) and the Core will reset itself at the same time.

Blarg.

The red blinking issue was solved. That was a fault of my own while trying to track down the dark death. I have currently bypassed the dark death by not initializing anything upfront, just defining pointers and moving constructor logic to an init() method called in setup after initializing them.

The current issue is the 1 minute coma. I connect to WiFi just fine, but after 1 minute everything stops (though it continues to breath). Then if I wait, it’ll spit out the last action and reset itself. I will time this delay and see if it matches anything.

As far as socket timeout issue, I investigated the netapp_timeout_values set from firmware to common-lib, as it declares the CC3000 to have a default value of 60 seconds. The firmware, however, sets the value DEFAULT_SEC_INACTIVITY, which in common-lib’s config.h is 0, so infinity timeout. Dead end there.

I think the 60 second coma is highly likely tied to network activity. With latest master, try fiddling with the defines at the end of this file in the common lib to see whether the the amount of time until reset changes.

Curious…if I comment out WLAN entirely, the printer starts behaving in strange ways, as if corrupted data is getting sent to it triggering different visual settings.

Yes, I can send the code. It is my quick attempt at getting the old firmware to function on the new hardware so I know I can continue basic demos. This means it is not pretty, and hacked together…so we’ll see. :slight_smile: I’ll email it over if I don’t find anything with Zachary’s timeout settings he pointed out below don’t reveal anything.

Will try right now! Paaaaaaadding.

Nope. I had messed with INACTIVITY before when I found 60 seconds was the CC3000 default, but nothing changes when I mess with any of the other values either. :-{

K, testing your code. At least with latest master of the other two repos it’s reseting because of the watchdog, probably hard fault. I’ll use gdb to figure out where the fault is, as well as try it with the revisions you state above of the other libs.

Ok! I’ve fixed the 60 second coma. Hopefully this will be enough information for you folk to tell me what is probably getting triggered.

I setup my boards RGB LED to change colors once a second, so it was easy to see if something was holding up the loop. I noticed that despite claims in the thermal printer code it would block while printing, which can take anywhere from 2-3 seconds, averaging around 4-6 seconds, and sometimes even a little higher.

I removed the blocking code so the loop would keep zipping along even while printing, working on my own safeties to keep the user from providing input, and now it works just fine.

So! We know that the blocking delay is directly causing the problem, and for some reason it will work fine up until 1 minute passes. When the 5-6 seconds of occasional blocking are gone, the 1 minute coma doesn’t seem to occur. Any ideas? At the very least, I can move forward, but I’d love to understand the dangerous waters I’ve found myself in. :slight_smile: