ECONNRESET and core offline

I’m trying to track down a bug in my code but I cannot reprogram my core from the command line using “spark flash”. I have been able to do this fairly reliably but something in the last reprogramming seems to have put the core into a state where I cannot program it again. When I attempt to do this I get:

flash core got error: {“code”:“ECONNRESET”}

I’m not sure, but I think this means, essentially, the core isn’t listening. Is that right?
In my loop() function I write a full stop to Serial so I can tell everything is still running. On previous reprogrammings I have always been able (eventually) to see these dots popping up on a terminal emulator (TeraTerm). Now I cannot see these any more, so I suspect something is blocking within the loop() function. If loop() never exits, is this enough to prevent reprogramming?
Last time this happened I got it working again by doing a complete factory reset. Is that the only solution?
At the moment the core is sitting there with a slowly breathing cyan LED (so there is some life) but I cannot reprogram it. If I do a “spark list” it can see my core, but claims it is offline. Any thoughts?

Can you try again? The Spark :cloud: had some updates and API calls might take a longer than usual

Just tried again. I tried several times earlier and it always fails the same way. Pretty sure the fault is in my code somewhere. Just not sure if this is normal behaviour. I expected to be able to reprogram the core whatever my code was up to but that seems not to be the case.
Is there a list somewhere of the codes returned by the spark flash program and what they mean?
Meanwhile I shall do a factory reset…

Factory reset did the trick and allowed me to reprogram the core. I think my code was stuck in an endless loop waiting for the Serial1 transmit buffer to empty. This does seem to prevent reprogramming of the core.

1 Like

This is still happening and I’m pretty sure my code is correct now. At least it doesn’t hang and does what I want.

It doesn’t happen every time, but every few times I reprogram the core (using spark flash) it doesn’t want to know. Even though the LED is breathing cyan and everything seems normal, I get the ECONNRESET error. The only way out of this is to do a factory reset and reconnect my Spark core to my router. Then it will let me re-flash it. This gets a bit tedious after a while.

Is this normal behaviour?

That error seems more like an issue connecting to the spark :cloud: via Spark-cli itself.

What code are you running?

If spark list works, spark flash should work fine.

I’m running a fairly large program that makes use of Serial (for debugging) and Serial1 for communicating with another device using an RS485 datalink. Actually I didn’t use the Serial1 object but wrote something similar of my own that uses the same pins but provides more control of the serial port (I needed to know when the last byte sent had finished transmitting so that I could turn the RS485 transmitter off, and I didn’t need buffering). Other than that I expose one function and one variable to the Spark cloud and that’s about it.

Apart from the odd pause now and again it seems to work fine. The RS485 datalink seems to work reliably and I can communicate with the core using a web page with JavaScript.

No “spark list” doesn’t work. When the problem occurs it always reports that my core exists, but is offline. Normally it says it is online.

So if spark list doesn’t show the core, it’s probably some code that knocked it offline.

Test it out with the default tinker app. If you are able to consistently interact and update code with the tinker app, then we can narrow down to the code issue.

The :cloud: has been pretty stable this week. :wink:

OK. I tried re-flashing the Tinker app 3 or 4 times from within the Android Spark app. It worked every time and I could toggle the blue LED on D7 on and off without problem.

If it is a code problem, what sort of things should I avoid doing?

At the moment the code in the loop function looks like this:

void loop() {
  long now = (long)millis();
  if( now - txTime >= 0L ) {
    // More code here.
    // Disables and re-enables interrupts.
    // Never takes longer than 20 ms.
    txTime += 200L;
  }
}

So normally it does very little, but every 200 ms it transmits a 16 byte message on TX pin and receives a 20 byte message on RX pin and whilst doing this it disables interrupts. Baud rate is 38400 baud. This code should never take longer than 20 ms to execute.

Is there anything here to watch out for?

The other possibility is that the code is overflowing the available space in some way. On compiling I get:

Memory use:
   text    data     bss     dec     hex filename
  88176    1276   12788  102240   18f60 /spark/compile_server/shared/workspace/3
_compile-server2/core-firmware/build/5097a6041f1a4e9f72517eae6041ef66f6be3c43e6f
f8ad2ff4358b27d05.elf

Haven’t worked out exactly how much program space I have and how much I am using, but does this look alright to you?

I can’t really compute the free space left off my head simply because i haven’t really been calculating this. :smiley:

FLASH: (88176 + 1276) / 110592 = 80.9%
RAM: (1276 + 12788) / 20480 = 68.7%

Looks decent…

I would try to run the basic code by commenting out the interrupts etc… Probably like the code you posted above with out all the other code and test it out first…

OK. I wrote a test program much like you suggested. All the code that did the RS485 communications has gone and replaced this with code that toggles the state of the LED on D7. Interrupts are no longer disabled.

I seem to be able to flash this to the core without problems. The core doesn’t seem to go offline, although I haven’t done an exhaustive test.

The weird thing is I can often flash the problem code without any problems. The problem does not appear every time. I can’t understand why it would work sometimes but not every time. I shall investigate further.

Thanks for the help.

2 Likes