The long awaited impOS 30 will be released on Monday Aug 25th!
This is a huge release, and we are very excited about it. Some of the really great things in this release are listed below, but you’ll definitely want to checkout the complete Release Notes (if you haven’t already):
Better support for BlinkUp
Better support for when the WiFi driver crashes (should resolve the ‘Device Restarted: WiFi Error’ bug)
Support for imp003
Improvements to the UART class to let you read blobs rather than individual bytes
Two of my devices have gone offline after the “firmware update triggered.” Looks like I’ll need to power cycle those to see if they come back online. All others seemed to come back up just fine. These two (along with others that did not experience problems) are on cellular connections. If the firmware update is large enough, they may have had problems getting the update completed without interruption.
One of a couple of mockups in the field stopped running after a power cycle. According to the log it repeats this behavior continuously:
2014-08-27 15:42:26 UTC+2 [Status] Device Booting; 2.44% program storage used
2014-08-27 15:42:42 UTC+2 [Exit Code] imp restarted, reason unknown
2014-08-27 15:42:42 UTC+2 [Status] Device Booting; 2.44% program storage used
2014-08-27 15:42:59 UTC+2 [Exit Code] imp restarted, reason unknown
…
New sketches download fine. I have reduced the code to the following. If I comment out the code line with hardware.uart57.configure, then it runs, otherwise the above behavior.
It seems in accordance with the updated documentation. Something incompatible with the new firmware?
`
// IMP001 based mockup with led on pin 2 and RX RF module serial on pin 7
state <- 0;
// Call back function for serial data
function readSerial() {
local result = 0;
result = hardware.uart57.read();
}
// Hellow world blink example
function blink() {
state = 1-state;
led.write(state);
imp.wakeup(0.5, blink);
}
// Configure and start
hardware.uart57.configure(2400, 8, PARITY_NONE, 1, NO_TX, readSerial);
led <- hardware.pin2;
led.configure(DIGITAL_OUT);
server.log(“Started …”);
blink();
`
I’ve tried that code in an imp001 here and it seems to be fine. Are you sure there isn’t some hardware reason why this unit dies after about 15s? Are both of your mockups running the same Squirrel code on the same hardware?
I have a SolderCore connected to a CradlePoint router via Ethernet and an imp001 connected via WiFi to the same router. The router is connected via USB to a MiFi device. This configuration has been in production for months. Historically, the imp001 performed extremely well–passing data nearly every minute of the day. However, that has gotten worse since the firmware update. The SolderCore is passing data most of the time and missing data is an indicator of acknowledged intermittent cellular issues. The imp is now restarting about every 12 minutes or so and reporting “imp restarted, reason: wifi outage”. It’s odd – it seems the device does an agent.send() and then disconnects soon thereafter. I’ve never seen this pattern. BTW, the imp001/imp002 have always outperformed the SolderCore–one of the reasons we switched to the EI platform.
I haven’t read of any WiFi code changes in the update that would cause this, but I may be overlooking something. My code has not changed other than adding a startup function to log the firmware version.
(side note – the imp001 did have trouble getting the firmware update, so I had to bring it to the office and let the update take place over our Internet service).
I have done nothing with imp.setpowersave() – quite honestly, I wasn’t even aware of it!
I have other imps in the same configuration, so I’m going to “assume” it’s a poor cellular connection for some reason that may be presenting itself as “wifi outage”. I’m off to change the cellular modem.
(Updated 20140828 11:00 EDT) I believe the part of the problem had to do with the cellular connection. However, I had to do a Blink-up to get the imp001 to come back online after returning it to the site (the SSID and credentials had not changed).
Thanks Peter. Hardware reason yes and no. It appears the new firmware is sensitive to a hardware reason, that has been there for a long time.
Similar code has been running on 4 mockups on and off in a period of a couple of months now. The 2 currently active mockups dropped off today. And on 2 breadboards with April boards running for 1-2 years - they also stopped working today. Last heard from the units at these times (CEST):
20140827 at 13:08 Mockup
20140827 at 09:07 Mockup
20140827 at 09:55 Breadboard
20140827 at 09:34 Breadboard
On a breadboard unit I have located the offending hardware wire as the RF module data out connected to imp001 pin7 (pictures). The RF module is this one: http://bit.ly/1lwm0R7
It is a 5V signal (and the imp is not 5V tolerant). It appears it has worked for 1-2 years for mockup demo purposes, until the firmware update rolled out?
A real product is being designed, and there is of course already a level shifter in it.
If I comment it out everything is ok, and if I leave it in with an empty function for a handler it restarts. I can’t really remove the NO_TX like @ThermIT as I need the other pin (RX) as a DIGITAL_OUT.
I have 5 imps with different projects and have been working flawlessly for months now even year+ some of them. Since the new update 4 out of 5 of them show me a [Status] Device disconnected after a while.
Is there anyway to revert to an older Release?
The network also should not be the issue. I have 3 of theses devices into one location and 2 in another. Also most of them are connected to different access points, and devices connected to these access points seem to work without problems. But I did restart all networks in both locations just in case but i still have issues.
My imps updated to the latest code as well with no issues. But i still keep losing them.
ElectricImp engineering please fix this again, i had a piece of mind before, now i keep on losing my imps
