Hi mnf,

I’ve seen another customer have this issue but haven’t been able to reproduce it myself. It’s tough because it seems to come up only after extended logging.

I have been working on this issue, here is what I’ve figured out so far:

The only place that a perpetual non-responsive blink is built in to the code is in the calibration routine, which is only supposed to run in the factory. It’s not even listed among the blink codes because a customer should never see it.

Under normal circumstances, the calibration routine will only run if the calibration data is blank. Since resetting the meter resumes normal operation, the calibration data is obviously intact. So something in the code is causing an erroneous jump to the calibration routine.

There are two true “threads” (ie. they have separate stacks) on the meter, one for talking to SD and one for everything else. My suspicion is that an unfortunate alignment of a bluetooth event and an SD card event is causing a stack overflow, resulting in an erroneous jump. Usually the meter can recover from this because the watchdog timer will elapse and reset the meter, but the special blink in the calibration routine specifically sidesteps this because in the factory we want to give the operator time to recognize the problem and address the issue before resetting the meter.

Anyway, sorry for the wall of text, this one is squirrely but I’m looking in to it. Thanks
~James