-
my bad, I wrote puck.js, I meant http://www.puck-js.com/puck.js, the script for communications you offer.
there is a loop locking problem for sure, I have verified it using espruino 2.14 on the p8 watch, I will try to explain better.
when using the code on this example* for communicating from a web page to an espruino device, two way comms, say sending from the device to a web page a string 40(so that the info gets split on 2 or more packets) characters long every 200ms, all is fine as long as the signal is strong. When the bt signal goes low or near lost, the espruino device reboots. You can verify it very easily, just have a led blink on every loop on the device, and force a bad signal on the phone running the web page. You will notice that the led blinks slower as signal gets worse, and eventually a reboot will follow.
I used characteristics and all is ok for me now, just reporting it in case you want to test.
enaon-
just have a led blink on every loop on the device, and force a bad signal on the phone running the web page.
which loop do you mean is there some specific looping code you can link (your code or that puck.js)? One idea is watchdog - if you have watchdog kicking in setInterval then any busy loop or delay in native code preventing intervals from running could trigger such reboot. Another issue causing this may be be overflowing the stack or memory - generating data faster than it could be sent filling memory or call stack (by somehow nesting calls when error happens?)
fanoush
That looks great!
It's hard to know what might be the issue with the communications I'm afraid. It's not something that I've heard of before with other Espruino nRF52832 devices communicating with each other, so I guess it could be an older firmware/softdevice on the DSD6?