What can I deduce from "imp restarted, reason: error recovery"?

2020-08-11T22:26:28.110 +12:00 [Exit Code] imp restarted, reason: error recovery

I get this message when I try to test uart2 (rxing data) on the imp005. It doesn’t happen every time. I’m not familiar with it. I’m carrying out tests on all the uarts and it’s just this one that seems to be playing up.

The “reason: error recovery” means that the watchdog timer has fired. This is nothing that Squirrel code can cause directly, and usually indicates either a bug in the improm firmware itself, or a hardware issue causing something to stall. I don’t think we’ve previously heard of imp005 uart2 issues causing watchdogs – that stuff is quite solidly system-tested. What improm version are you using? (imp.getsoftwareversion) Could you let me know your device ID (hardware.getdeviceid), by private message if you’d prefer, so that I can go and look in our crash logs to see if there’s anything there that sheds any more light on it? What’s the hardware – is it an imp005-breakout or a board of your own design?


HI Peter,

this is a new imp005 board of our own design. The id is 5000d8c46a56e45c. We began testing the design Tuesday morning, UK time. We were looping back data from one uart to another to test that our tx and rx connections were correct. We did this with all the uarts and we only saw this error when trying to send data from uart0 to uart2. It’s intermittent, occurring about 33% of the time.
I note that the only time that I found someone mentioning “error recovery” on the forums, they were also doing the same thing, rxing data on a uart. They didn’t specify which imp they were using.

ee282aa - release-40.14 - Mon Aug 3 08:56:08 2020 - production

This topic was automatically closed after 60 days. New replies are no longer allowed.

Apologies for the terrible delay. Your crash report wasn’t showing up in the logs for some reason, but it’s there now. Unfortunately it doesn’t shed much extra light. Is there any chance that you were trying to use uart2 without configuring it first? Such attempts should be disallowed, of course, but we’ve had some issues with that code path in the past.

(In retrospect, we should have arranged that such errors were impossible to make, by putting the read() and write() methods on an object that only gets returned from configure(). But obviously we can’t change that now.)