analog sensor read crashes spark core #23
Comments
|
Thanks for the report, I will build this circuit and try to repro :) |
|
This was a massive bug. You deserve an ice-cream or a beer for this report. |
|
Will buy the beer! Chris Williams @voodootikigod http://twitter.com/voodootikigod | GitHub The things I make that you should check out: Help me end the negativity on the internet, share this On Tue, Jun 10, 2014 at 3:56 PM, Rick Waldron [email protected]
|
|
@Resseguie can you help me test this: https://github.com/voodootikigod/voodoospark/tree/redesign-with-buffer-cache thanks! Related: https://github.com/spark/core-firmware/issues/221#event-130001665 |
|
No problem happy to help. I'll look forward to that beer at the next jsconf :) |
|
@rwaldron Working on it now. I'm new to Cylon.js. What is the reference to |
|
I loaded the voodoospark version from your buffer-cache branch. Here's what I tested with: And I get: I, [2014-06-11T02:06:44.152Z] INFO -- : Initializing connections...
I, [2014-06-11T02:06:44.162Z] INFO -- : Initializing connection 'voodoospark'...
D, [2014-06-11T02:06:44.163Z] DEBUG -- : Loading adaptor 'voodoospark'
D, [2014-06-11T02:06:44.328Z] DEBUG -- : Registering Spark adaptor for Robot 67322
D, [2014-06-11T02:06:44.328Z] DEBUG -- : Registering GPIO AnalogSensor driver for Robot 67322
D, [2014-06-11T02:06:44.333Z] DEBUG -- : Registering GPIO Button driver for Robot 67322
D, [2014-06-11T02:06:44.333Z] DEBUG -- : Registering GPIO ContinuousServo driver for Robot 67322
D, [2014-06-11T02:06:44.333Z] DEBUG -- : Registering GPIO LED driver for Robot 67322
D, [2014-06-11T02:06:44.333Z] DEBUG -- : Registering GPIO MakeyButton driver for Robot 67322
D, [2014-06-11T02:06:44.333Z] DEBUG -- : Registering GPIO Maxbotix driver for Robot 67322
D, [2014-06-11T02:06:44.333Z] DEBUG -- : Registering GPIO Motor driver for Robot 67322
D, [2014-06-11T02:06:44.333Z] DEBUG -- : Registering GPIO Servo driver for Robot 67322
D, [2014-06-11T02:06:44.333Z] DEBUG -- : Registering GPIO IR Range Sensor driver for Robot 67322
D, [2014-06-11T02:06:44.333Z] DEBUG -- : Registering GPIO DirectPin Driver for Robot 67322
I, [2014-06-11T02:06:44.333Z] INFO -- : Initializing devices...
I, [2014-06-11T02:06:44.333Z] INFO -- : Initializing device 'led'...
D, [2014-06-11T02:06:44.333Z] DEBUG -- : Loading driver 'led'
I, [2014-06-11T02:06:44.334Z] INFO -- : Initializing device 'sensor'...
D, [2014-06-11T02:06:44.334Z] DEBUG -- : Loading driver 'analogSensor'
I, [2014-06-11T02:06:44.334Z] INFO -- : Starting connections...
I, [2014-06-11T02:06:44.334Z] INFO -- : Connecting to voodoospark
I, [2014-06-11T02:06:44.807Z] INFO -- : Starting devices...
I, [2014-06-11T02:06:44.808Z] INFO -- : Starting device led on pin D7
I, [2014-06-11T02:06:44.808Z] INFO -- : Driver led started
I, [2014-06-11T02:06:44.808Z] INFO -- : Starting device sensor on pin A7
I, [2014-06-11T02:06:44.809Z] INFO -- : Driver analogSensor started
I, [2014-06-11T02:06:44.809Z] INFO -- : Working...
-32 celsius or -26 fahrenheit
-32 celsius or -26 fahrenheit
...
-32 celsius or -26 fahrenheit
-32 celsius or -26 fahrenheit
-32 celsius or -26 fahrenheit
-32 celsius or -26 fahrenheit
events.js:72
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at errnoException (net.js:904:11)
at TCP.onread (net.js:558:19)Behaves just as described by @m4strmind. Invalid temp readings, then after a while the Spark crashes and reboots. |
|
When it crashes does the LED turn red flashing? Chris Williams @voodootikigod http://twitter.com/voodootikigod | GitHub The things I make that you should check out: Help me end the negativity on the internet, share this On Tue, Jun 10, 2014 at 10:13 PM, David Resseguie [email protected]
|
|
@voodootikigod yep |
|
like a dot dot dot dash dash dash dot dot dot (SOS)? Chris Williams @voodootikigod http://twitter.com/voodootikigod | GitHub The things I make that you should check out: Help me end the negativity on the internet, share this On Tue, Jun 10, 2014 at 10:22 PM, David Resseguie [email protected]
|
|
Yes, looks like SOS repeated two times. Video uploading to YouTube presently. I'll post link when it's ready. |
|
Means it is out of memory... I can track it front here (assuming I can find Chris Williams @voodootikigod http://twitter.com/voodootikigod | GitHub The things I make that you should check out: Help me end the negativity on the internet, share this On Tue, Jun 10, 2014 at 10:32 PM, David Resseguie [email protected]
|
|
For completeness sake, here is essentially the same thing using |
|
Sounds like it's probably not needed at this point, but since I promised, here is a video of the crash running the cylon.js program: |
|
Yup memory issue. Will clear. On Tuesday, June 10, 2014, David Resseguie [email protected] wrote:
Chris Williams @voodootikigod http://twitter.com/voodootikigod | GitHub The things I make that you should check out: Help me end the negativity on the internet, share this |
|
Note, I had copied that @m4strmind You'll want to note that I made the same temperature calculation adjustments to the @rwaldron Once the memory issue is fixed, I'll do a PR to put the |
|
@Resseguie cylon isn't relevant here, I didn't even bother with it since the same issue was reproducible using just spark-io. @voodootikigod I'm already knee deep in this... Most of the issues with memory are supposed to be resolved with a new core-firmware release this week |
|
This buffer caching branch is a necessary evolution as voodoospark was previously losing data and missing actions as a result. |
|
@rwaldron should be available in irc today, if you need/want help just ping Chris Williams @voodootikigod http://twitter.com/voodootikigod | GitHub The things I make that you should check out: Help me end the negativity on the internet, share this On Wed, Jun 11, 2014 at 12:55 AM, Rick Waldron [email protected]
|
|
Will do! :) |
|
@Resseguie fyi the ./connection was my doing. I do that just to keep from accidentally forgetting to remove my spark token from different copy/pastes around the intertubes. I just stash the connection in a separate file. Sorry for the confusion. |
|
@m4strmind No problem, I figured that was the case. I've gotten in the habit of using |
|
|
|
@julianduque code? |
|
@rwaldron this single line is crashing the app, not even listening the I also tried with I'm using |
|
@Resseguie was working on this I think, but don't remember how far he got (I might even be mistaken) |
|
I'll see if my C skills are good enough to figure out what the problem is ;) |
|
I am flushing out a couple things, will put this in the queue. Chris Williams @voodootikigod http://twitter.com/voodootikigod | GitHub The things I make that you should check out: Help me end the negativity on the internet, share this On Tue, Oct 7, 2014 at 10:02 AM, Julian Duque [email protected]
|
|
@julianduque can you try this branch: https://github.com/voodootikigod/voodoospark/tree/memset-restore |
|
FYI, I tested the OP (using TMP36) after the recent buffer overflow fix ( #33 ) and it still gets an SOS as before. I was hoping it was related. Here's the gist that still fails: |
|
Looks like it starts at 100, but I wonder if we change this to something faster, but put some tiny delays in between the reads? https://github.com/voodootikigod/voodoospark/blob/master/firmware/voodoospark.cpp#L153 Add a delay here https://github.com/voodootikigod/voodoospark/blob/master/firmware/voodoospark.cpp#L195 and see what happens. Keep in mind that I'm completely guessing right now and might be way off |
|
Whoops. Wrong button. |
|
I need peeps to test out master. |
Something must've become stricter on their end. |
|
Re-ran my tests with the updated voodoospark firmware on main (pin modes). Summary since we've got several test cases going on in this thread:
I should note that (1) above, when used with a tmp36 sensor as in the OP, returned valid readings both before and after the latest pin mode updates you put in. |
I'm going to try your specific steps after this, but I couldn't reproduce an SOS yesterday.
Exactly—we had all tested and re-tested this stuff. |
Can you give me an idea of how long until the SOS occurs?
I can repro this at 3 pins
Yeah, looks like the board just stops responding. |
|
On (1) it was probably 5-10 minutes. It was long enough that I thought it had been fixed initially, but then it SOS'd while I was preparing the next test. |
|
No matter what headway I make, this thing eventually SOS's. I'm beginning to think that we simply expect too much from it. |
|
Setting pinMode on 3 analog pins will crash the board. Setting pinMode on 3 digital pins will not. Why? (thinking out loud) |
|
And just like that... |
|
@Resseguie can you test with
Thanks! |
|
Following up with your earlier question, I just timed (1) from above. It took less than a minute this time to SOS with the existing voodoospark/spark-io. Then, trying your reporting-refactor, I ran into a compilation error on voodoospark. (See my inline comment on the commit.) |
|
Compiled that time. What specifically are you looking for? It still SOS'd after ~30 seconds but the analog values coming in from my tmp36 weren't correct after the refactor code was used. (Apologies, I only had time to do a quick test, not dig into the changes you had made.) |
|
@Resseguie can you test with:
|
|
@rwaldron will do. I should have a few minutes tonight after kids go to bed. |
|
@rwaldron sweet, My (1) example with tmp36 has been running for over 20 minutes w/o hiccup! Thankful for Google when I see stuff like this: |
Just ask! This is a neat side effect of removing the sparse array checks from new Array APIs in ES6 :) |
|
FYI We passed the hour mark. Initial tests on 2-3 also came back positive. |
|
Argh. After about the 1:!5 mark I finally got an error. But it wasn't the usual SOS. In this case, it started flashing cyan (lost network connection?) and it never recovered. It would occasionally start flashing red, then back to flashing cyan. I didn't notice the SOS pattern, but perhaps I missed it. But I'm not sure this particular fault is related to what we've been working on. More likely related to it just losing connectivity and then losing it's mind. |
|
Can you run some other tests to make sure everything else is in working order? I did a few things, but I need your confirmation |
|
Discover similar issue, it seems to also be related to #32 : this code breaks the board and makes it impossible to connect again unless you disconnect and reconnect the board or do a reboot: var Spark = require("spark-io");
var board = new Spark({
token: 'token',
deviceId: 'device_id',
});
board.on("ready", function() {
console.log("CONNECTED");
this.pinMode("A0", this.MODES.ANALOG);
this.pinMode("A1", this.MODES.PWM);
var byte = 0;
// Log all the readings for A1
this.analogRead("A0", function(data) {
console.log(data);
});
// This will "blink" the on board led
setInterval(function() {
this.analogWrite("A1", 128);
}.bind(this), 1000);
});I just wanted to do an analog read from a potentiometer and regulate the brightness of an LED with the This is the output: $ node spark-io.js
CONNECTED
529
528
528
530
530
528
531
527
531
531
525
525
525
527
events.js:72
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at errnoException (net.js:904:11)
at TCP.onread (net.js:558:19)
And this is a video of the board rebooting and acting all loco when it stops and before showing the error, seems like it restarts but after that needs a hard reboot or unplug to be able to connect again: |
|
Well, it seems if I try to connect again, and let it be for some minutes, it starts flashing cyan fast and then turns off, completely off. |
|
@edgarsilva thanks for another test case. I wanted to capture some notes from my initial tests. I got inconsistent results using your example and the latest updates from @rwaldron First run of your code, I also got an SOS red flash pretty quickly. But then I ran it again a few minutes later and it chugged along for an extended time without problem. I made a few test cases to try and isolate the issue and add some timers. (1) I isolated just the analogRead calls: (2) Doing just the analogWrite inside setInterval: (3) I combined the above two (basically your example but with some timers in place): I never got an SOS with the first two. (Though I didn't run them long term, just for a few minutes each.) With (3), it sometimes ran for a while fine, but usually SOS'ed. Sample output from one of the runs that failed quickly: Interesting that the reads stopped but the writes continued for a while before the SOS. The Core was jacked up every time after the error. It's pretty usual that I have to reboot a Core after SOS but it seemed like it was particularly difficult to get it to reconnect tonight. Had to power it off and on multiple times before I could get it to connect again. I'll need to do formal testing again and capture DEBUG output, but I'm out of time for the night. |
|
That pretty much seems like the same behavior I've been getting, I'll try to isolate and have more debugging info next week, see if we can find the root cause. |
|
This has been fixed for some time |
I discovered a bug that is related to voodoospark when using cylonjs. I believe this is a problem with voodoospark and not cylonjs.
if you build this circuit http://docs.spark.io/assets/images/breadboard-temp-sensor.jpg and run this code http://pastebin.com/9acm0AjY.
The default tinker firmware will run the application fine.
if you update to voodoospark firmware the sparkcore will not return proper values for the temperature reading, and shortly red light the core and it will crash the hardware and restart ending the application.
The text was updated successfully, but these errors were encountered: