I have been using Spark now for quite sometime and want to bring to your attention this problem. This is showstopper for me to prodcutize.
- My application is taking some 55 bytes input from Serial Port every 3 sec or so
- It publishes this to the cloud immediately.
- I see sometimes Spark loses connection to cloud but gets back to normal state in few seconds. I can live with that althought would like to root cuase it also.
- After approximately 18 - 20 hrs, Core resets, show green flickering LED, gets back to cloud, start breathing Cyan as if everything is OK.
- I had put in debug messages on USB to check what is the issue at that time but to my surprise, core had not enumerated so no Serial Port could be connected.
- I just manually reseted the core and it came back without any issue.
- Second time this happened. I tried to reflash new code through internet to see connectivity, I was able to do it without any problem.
- This is very big problem for me, if Core resets and does not come back to original state and requires users intervention.
- There is no way I can productize this if I will have to run service calls for resetting the core.
- I am using latest firmware and compiling my app with that.
How can I debug this further and provide logs etc since Serial Port is dead after it resets? I have JTAG debugger so can put some breakpoints if someone suggests where to put it.
Further I created 4 line app which just publishes message every 3 sec and does not receive anything on UART . This is just to rule out any thing to do with UART. It is running right now but will have to wait for some hrs before that condition happens.
I think your code is crashing somehow and the core decides to run the backup firmware which unless you do something special is the Tinker app that your core came with.
Next time this happens see if you can access the Tinker API from a phone or via curl for this core.
It does this after a serious crash to avoid bricking the core.
Probably the best thing to do is figure out why your code is crashing.
Make sense. That is why I was able to flash the code back in. I will check why my code is crashing. Most likely due to something on the UART causing this issue but what is strange is why Core went back to backup firmware. Also why USB did not enumerate is also puzzling.
I don’t think Tinker enumerates the USB connection. If the code doesn’t call a Serial.
being()begin() the core won’t “tell” the computer it’s a serial port so I imagine that’s what is happening as well
@harrisonhjones, wow a new life form… Serial.being
My ability to type/spell is deteriorating at a terrifying rapid pace
It is incorrect. In Tinker I can see Core enumerates as USB Serial device. Since Tinker app does not send any data when connected it don’t see anything on the serial port.
Anyways, I looked into my UART processing code and don’t see any issue with it. I will be debugging more but Core not recovering to the same state is a serious issue. It need to be fixed.
I just checked the sources and Tinker does not start the USB serial device and should not enumerate when connected to USB. If you are seeing different behavior, perhaps you are not running Tinker.
You are in full control of what firmware the core runs after multiple failures and by using dfu-util you can put your own firmware in the factory reset flash location. I would caution you strongly not to do this until you understand the problems you are having, but if you check the hardware memory map, you can overwrite the factory reset firmware location with whatever program you like.