Clock stopped

[espruino-discuss3]

Posted at 2016-07-01 by jonreid

I have just observed the clock stopping ie every call to getTime() returns the same number. This obviously causes my code to stop as all the setInterval code stops firing. Doing a setTime() started it again

My unit is battery powered and I think this happened after I removed the external DC power which feeds the battery charger - so there may have been some sort of voltage event that occurred.

We have another unit working in the field for several weeks and then stop - so I am thinking the same thing happened.

Any ideas what is going on ? How can I recover from this as setting the watchdog did not seem to help.

[espruino-discuss3]

Posted at 2016-07-02 by @gfwilliams

Hi Jon,

Do you have an external watch crystal on the Espruino? And is the firmware up to date?

I managed to get this recently on a Pico when there was a really bad power connection, and it kept powering on and off several times a second. Thinking about it, if it gets powered off right in the middle of initialisation, at just the right point, when it powers back on it could think that it has an external oscillator when it doesn't.

I'm really surprised that setTime fixes it though - are you sure? If so, it might not be what I think it is at all.

To fix it, unplugging, waiting a few seconds and then plugging back in should work fine.

---

Posted at 2016-07-02 by jonreid

It is a standard Pico running latest firmware as of a week ago.

I noticed my code had stopped from lack of activity on the LCD so hooked up right away to the IDE. I am not convinced that the clock stopped when I removed DC to the charger but it is possible.

I checked the error flags and nothing was set. Turning on the watchdog did not reboot. The Pico seemed responsive in all the normal ways apart from getTime returning the same value and hence no set interval functions being called.

I am 99.9% sure that setTime is what started it again. FYI I also use a Clock object and regularly set the Clock object time to what I get from the SIM800 module. (Can't remember if I create a new object or call setClock)

I do need to get a more accurate Pico clock running for the case where the GSM connection is down, do I need to add an external crystal to achieve that? Currently the clock runs about 10% fast.

But the most important thing is I need to detect and recover from the stopped clock as it is a 24x7 logging application and so cannot manually re power to fix.

---

Posted at 2016-07-03 by Sacha

I have a lot of picos running 7/24, powered DC 5v. I discovered also that some picos (V1,85) does not fire setInterval anymore, everything else is working. I do not have a special crystal. But i sync the time via xbee from a server. So i call every several minutes setTime().

@gfwilliams: Could it be that when i use setTime() to correct the current time that setIntervals are lost because i corrected the time a huge amount to the future ?

I have to dismount carefully a affected pico without powerloss to discover in the IDE what's the state. Is there a way to debug setTimouts or setIntervals ?

Thanks
Sacha

---

Posted at 2016-07-04 by @gfwilliams

@jonreid - thanks, I'll post up some code in a few minutes that we can hopefully use to try and debug this more - so if you have any Picos that currently have the issue, if you could keep them running it'd be a huge help.

For the crystal, the Pico is a bit picky - you need an ABS06-107 (the 107 bit is important): http://uk.farnell.com/abracon/abs06-107-32-768khz-t/crystal-32-768khz-4pf-2-x-1-2mm/dp/2467860

Then you can solder it (and two 2pF 0403 capacitors) to the pads on the end of the board. It's a bit fiddly, but once done you should get accurate timekeeping.

I do have plans to try and improve the timekeeping (by ignoring the internal oscillator and using the high speed oscillator when not in deep sleep) - but if you are using deep sleep then that wouldn't be any use to you.

Sacha - the thing to do would be to just connect to the PC - either USB, or via serial on B6/B7 and firstly, look at getTime() twice in a row and see if it changed - and if it hasn't then try the code I'll post up in a few minutes.

---

Posted at 2016-07-04 by @gfwilliams

Can you copy/paste the following into the left-hand side, and tell me what it says on a Pico where the clock has stopped?

var RCC = {
  "a": {
    "BDCR": 1073887344,
    "CSR": 1073887348,
  },
  "f": {
    "BDCR": {
      "LSEON": 1,
      "LSERDY": 2,
      "LSEBYP": 4,
      "RTCSEL": 768,
      "RTCSEL_0": 256,
      "RTCSEL_1": 512,
      "RTCEN": 32768,
      "BDRST": 65536
    },
    "CSR": {
      "LSION": 1,
      "LSIRDY": 2,
      "RMVF": 16777216,
      "BORRSTF": 33554432,
      "PADRSTF": 67108864,
      "PORRSTF": 134217728,
      "SFTRSTF": 268435456,
      "WDGRSTF": 536870912,
      "WWDGRSTF": 1073741824,
      "LPWRRSTF": 2147483648
    },
  }
};

function test() {
  console.log("LSEON",peek32(RCC.a.BDCR)&RCC.f.BDCR.LSEON);
  console.log("LSERDY",peek32(RCC.a.BDCR)&RCC.f.BDCR.LSERDY);
  console.log("LSION",peek32(RCC.a.CSR)&RCC.f.CSR.LSION);
  console.log("LSIRDY",peek32(RCC.a.CSR)&RCC.f.CSR.LSIRDY);
  console.log(["NONE","LSE","LSI","HSE"][((peek32(RCC.a.BDCR)&RCC.f.BDCR.RTCSEL)>>8)]);
}

test();

Thanks!

---

Posted at 2016-07-04 by jonreid

OK, will try that next time I catch one. The main problem is that in many weeks of operation, across several units I have only seen this definitely once (but probably once in the field), so it could take a while to appear again.

We are putting more units into the field in the next few weeks so hopefully this can be trapped before then.

---

Posted at 2016-07-04 by Sacha

Hi Gordon
I just hooked it up on USB. The clock has not stopped. getTime() gives me increasing results.
Uploading my code again fixed it.
I think there is a issue with setTime(). I try to reproduce it.
Sacha

---

Posted at 2016-07-04 by Sacha

Hmm. I have to correct my self. After unplug the USB connection (Still powered) DC 5v my setIntervals are not called again. Is the pico powerd over USB even when I have a external PSU connected ? If yes, could my litte psu causing the problem ? But only the clock affected ?

Thanks
Sacha

---

Posted at 2016-07-04 by Sacha

I connected another PSU. No problem anymore. The clock or the setIntervals are called.
If you buy crab you buy twice or what ? With this china psu I have the described problems:

http://www.aliexpress.com/item/220V-to-5V-2W-ac-dc-power-supply-width-voltage-input-85-264V-Smart-Home-AC/2036637836.html?spm=2114.13010608.0.57.vTpPwd

No problem with this:

http://www.myrra.com/myrra/AC-DC/Electronic-transformers/p/Electronic-transformer--Switching-power-supply--3-3V--2-5W--regulated/0000003LZW

How can it only affect the clock or setIntervals/setTimeout ?

Sacha

---

Posted at 2016-07-04 by jonreid

Hi Sacha, Can you please generate the fault - using the bad power supply - and then run Gordons code, there may still be a software improvement that could be made

---

Posted at 2016-07-05 by @gfwilliams

@sacha which pins have you connected the power supply to?

It'd be worth checking the voltage coming out of it, and ideally looking at it with an oscilloscope to check that it's stable. But as @jonreid says, running that code would be a huge help, as it might be it's getting confused about the clock source.

---

Posted at 2016-07-05 by Sacha

I had the some problem with the new psu too. It was the first impression. I need more time to investigate my code as well.
@gfwilliams will try to run your code as well. I connected the power to the pins marked with the blue arrow.

---

Attachments:

• pico.png

---

Posted at 2016-07-06 by @gfwilliams

Yes, those connections are great to use...

I just release 1v86 and it's got the E.kickWatchdog() function - so hopefully that is an option to ensure this always stays running, even if it's not a perfect fix.

For instance:

E.enableWatchdog(1/*second*/, false);
setInterval(function() {
  E.kickWatchdog();
}, 500);

---

Posted at 2016-07-06 by jonreid

Thanks Gordon, that is a great fallback for now. So this will still work in the condition where getTime is returning the same value ?

---

Posted at 2016-07-06 by @gfwilliams

Yes - so if it returns the same value, the interval won't get called, and within 1 second it'll do a hard reset.

Hopefully the hard reset will fix the problem - it's possible the hardware itself has got into some strange state though in which case it won't - but let me know either way, it helps to track things down!

---

Posted at 2016-07-06 by Sacha

Gordon
Tried to run your code by copy it into the left side. Got:

>test();
Uncaught ReferenceError: "R" is not defined
 at line 1 col 40
console.log("LSEON",peek32(RCC.a.BDCR)&R­CC.f.BDCR.LSEON);
                                       ^
in function "test" called from line 1 col 6
test();

---

Posted at 2016-07-06 by @gfwilliams

Try copying it into the right-hand side then copy-pasting into the left.

The forum sometimes inserts unrenderable characters into the code (I have no idea why). The RHS takes them out when pasting, but maybe the LHS doesn't.

---

Posted at 2016-07-06 by Sacha

Worked this is the output while setInterval is not anymore called:

test();
LSEON 0
LSERDY 0
LSION 1
LSIRDY 2
LSI

---

Posted at 2016-07-06 by @gfwilliams

Hmm - thanks! Well, at least that shows it's not a hardware initialisation issue, since the low speed internal oscillator is selected and on.

Can you check getTime() and see if that increments?

Also, you can view what timers you have by doing print(global["\xff"].timers) - it'd be interesting to see if the 'time' on them changed at all

---

Posted at 2016-07-09 by Sacha

Many thanks for your help Gordon. I think i found the problem. It was self made. In a special situation i called clearTimeout() with an undefined var. This cleared all intervals.

Sacha

---

Posted at 2016-07-10 by Sacha

Gordon. Please include this command in the reference page of setInterval/Timeout.
"print(global["\xff"].timers);". This will help others debugging those functions.
Thanks
Sacha

---

Posted at 2016-07-10 by @gfwilliams

I should add a special function for that - I'll make a note. The whole global["\xff"] thing is a bit of a hack really, even if it's good for debug :)