Unsolved Error: Spark Core Power Cycling

Troubleshooting
21

(that’s what I mean by ‘without applying the dfu-util firmware flash’)

22

paste the entire code you are trying to run with the following format:

``` <-- insert this

// paste code here

``` <-- insert this
23

@kennethlimcp I literally did. Above. That’s literally my entire program. I’m not kidding.

24

There's an extra }. It compiled?

You are publishing too fast i guess.

Try this

unsigned long old_time = millis()

void loop(){
 if(millis() - old_time >= 1000){
   Spark.publish("ping");
   old_time = millis();
 }
}
25

no - my typo

26

@kennethlimcp thanks but… unless you have a strong theory about why that might help, I am going to wait for someone from Particle to be awake on this one.

27

@star, though @kennethlimcp is not a Particle employee, as an Elite he is one of the best debuggers I have met. He regularly works with the Particle engineers to isolate member-identified bugs. All this to say that I would trust his judgement and his ability to assist both you and Particle to identify the problem. The code @kennethlimcp gave you is a solid testing platform and I recommend you use it. It will also help @mdma. :grinning:

2 Likes
28

Have you applied the deep cc3000 update? I would suggest that, or even getting the 1.14 update from https://github.com/spark/cc3000-patch-programmer/tree/ti-patch-1.14/

You may be running into this issue, which is fixed by upgrading to the latest CC3000 service pack.

1 Like
29

Did you try the code @kennethlimcp posted? It’s a good test - by removing the call to delay(500) you allow the system more time to perform background processing. Please try before and after performing the cc3000 update and let us know the results.

1 Like
30

I do think you’re running into what they’re talking about, but there was a key feature in your original code that may’ve been overlooked. You’ve got a while() loop, which I believe is a blocking function, instead of an if() to check how much time has passed. Definitely try @kennethlimcp’s and see, it’s a great test.

Helpful things to know:
In the current firmware, the execution of system code and user code is sequential- so it’s really system() -> loop() -> system() -> loop(). Anything that blocks in the loop, or hangs for too long, will interfere with the connectivity of the device, which all happens in system(). Definitely screws up your ability to flash new code if you’re running blocking code.

Here’s the other thing that happens: if you publish() more than once per second, you’ll be throttled. Throttling can also have consequences that look like poor connectivity, so 2Hz publishing can result in what behaviorally look like drops.

So! If you go from
while(now < millis() + 2000){}
to
if(2000 >= millis() - now){now = millis();}

Then I think that’ll smooth out the bumps.

1 Like