How to update Imp code when Imp is awake & running

I thought this would be very simple and automatic but apparently not.

I want to update the Imp code to a newer version. I am able to save that code inside the IDE. However, the IMP continues to run the old code which does not have any deepsleepfor or sleepfor calls. The brute force solution would be to unplug the imp device and restart it so that it picks up the new code. However, that’s not an option as this is a battery operated device which is placed in a remote location which is hard to reach.

Is there any interrupt that I could send from the agent to make the imp interrupt what it’s doing and just restart so that it picks up the new code?

There was an issue with imps that had been moved to the Erlang server having delayed timestamps:

…could have been that? Only logging was delayed. Were the timestamps correct? Got a mac address or device ID?

It is simple and automatic as long as you are not in an infinite loop; if you want to do repeated tasks, use imp.wakeup() to queue functions to run at a future time.

If you have a while(1) loop, the imp will never get to process any received traffic; this will mean that not only can you not push new code to the device, but you also can’t send messages to it.

Maybe post the code your imp is running if you can’t see where the looping might be happening?

Also see:

Hugo, that’s the simple behavior I had gotten used to without realizing it all this time because it was happening quite smoothly.

However, this evening it was strange when my updated device code was not getting pushed down to the device. I spent about 90-120 minutes trying to debug it. And the device kept showing server.logs from a previous version of the software. (BTW just to be clear there were no loops, leave alone infinite ones, in the previous version of the device software).

When I logged back in after a few hours and tried to push the code again (Command-S), it just worked automatically.

Have you seen this kind of behavior before? Did any others complain about this issue around that time of the day? I hope this is a one off issue and not something that’s seen too often.

Timestamps were correct. Mac address seemed correct.

Anyways it went away and I hope it doesn’t come again.


This effect was indeed visible on imps that also suffered from the Erlang server move ‘delayed timestamp’. It took up to 40 mins for a device to receive and switch to new code. Made me almost go through the roof.

Anyway, this is fixed now. Just mentioning it for those that have experienced it and are spending time trying to find bugs in their code :slight_smile: