Running Arduino Micro 24/7

Regarding delay, you are probably thinking of a multi-programming operating system, like Apple or Windows. In those cases, doing a delay let other programs run. That doesn't apply here.

Great! That has answered a lot of questions for me and put my mind at rest so thanks!

On another note, today I had some other serious issues with my Arduino micro board so I was hoping that you might have some idea.
After putting in the Watchdog timer reset, it pretty much appeared to kill the board.
I could no longer upload any program (not even the BareMinimum), the upload just got stuck for about a minute before timing out.
Both reset and powering off/on didn't fix it, rebooting PC etc..
I did a bit more digging and eventually found 1 fix which got it going again:

  • Hold the reset button. Start uploading. Release the reset button.
    Noting else worked!
    I tried to reproduce the WDT issue again and the same thing happened, exactly as before
    When testing this script on my Arduino Uno it worked without problem.
    Do you know if this is some nasty bug on the Arduino micro only since it works on the UNO? or could my script be wrong?
    I have put the script below, any ideas would be very helpful.
    Thanks again,
    Paul

#include <avr/wdt.h>
void setup() {
wdt_enable(WDTO_8S); // have the wdt reset the chip if 8s passes without a reset
}
void loop() {
wdt_reset(); // reset the wdt
}

It's a well-known problem with some versions of the bootloader on the Arduino Mega.

Installing a corrected bootloader will fix it.

Your technique (of holding down reset) stops the sketch from loading after a power-off, so the problem WDT is not activated.

Well he stated using an arduino micro board, which like the leonardo board uses a 32U4 chip, so I don't think his problem is based on the old 'doesn't handle WDT interrupts correctly' problem. I would think all the 32U4 based arduino products handle WDT correctly? And I would not think there are upgraded bootloaders avalible for this chip series anyway?

This sounds more like a problem the very first UNO boards had that if loaded with a sketch that started sending serial data immediatly effected the 8U2 USB serial chip from responding to the bootloader correctly, or something like that? It was fixed with a firmware upgrade to the 8U2, but I recall a work around was holding in the reset button, plug the board in and only release the reset when the upload started?

Lefty

retrolefty:
I would think all the 32U4 based arduino products handle WDT correctly?

Well the empirical evidence appears to be against that hope.

If anyone wants to try and knows how to reburn the bootloader in case the test results come out positive (or is that negative, I always seem to get that wrong :wink: ), below is a sketch that will 'brick' any bootloader that doesn't disable the WDT upon entry to the bootloader. Bricked both my mega1280 boards until I upgraded them to a optiboot.

// Test sketch to see if WDT interrupts are handled properly by the bootloader

/*
 Warning Warning Warning this is a semi-destructive test in that
 if your bootloader does not reset WDT interrupts upon starting 
 it will be forced into a tight loop of bootloader starts/WDT resets
 chip/bootloader starts again/lather rinse repeat. One can only
 recover to normal operation by reburning the bootloader with
 a ICSP programmer. If this sketch runs properly on a chip with a WDT aware bootloader,
 you will see continous serial output on the serial monitor.

Note that current arduino mega boards will fail this test and brick

*/

// Code from arduino forum poster (sorry name not remembered) 1/11/13

#include <avr/wdt.h>

void setup(){
  Serial.begin(57600);
  delay(100);
  Serial.println("Hello world");
  wdt_enable(WDTO_15MS);
}

void loop(){
  Serial.println("I am going to not get stuck..");
  for(int x=0; x<100; x++) {
    wdt_reset();
    x++;
    delay(10);
  }
  wdt_reset();
  Serial.println("I am going to get stuck now..");
  for(int x=0; 1; x++) {
    delay(10);
  }
}

Well I just happened to have an Arduino Micro to hand (recently received) so I tried your torture test.

It worked (the WDT did its stuff) and afterwards I could upload a new sketch.

Although ... this is strange. After powering it off and on again, even with the ASCII table sketch loaded (and nothing to do with watchdogs) the sketch didn't run. I could upload it again, and it would run, but it wouldn't run the existing one from power-off.

Yes, it seems really flaky.

I can upload new sketches, and after opening the serial monitor it runs them ... the first time.

I don't know about the rest of the folk on this board, but to me, the fact that we are still having problems with the dog gone bootloader after knowing for years that the problem exists is really, really annoying. Put the fix in the darn production line so we can forget it ever existed.

For the OP, there is a workaround that I developed while I was waiting (and whining) for a fix to the 2560 bootloader. You turn the bootloader into a timer and slap in some code to take care of the board locking up on something. It's not the absolute perfect solution since it isn't totally hardware, but it worked for months and months without a hitch in several arduinos of mine. I use it pretty regularly when I need a watchdog that can run a longer period than the provided one. This one can run a long time if needed (sky may be the limit).

Details are at: Desert Home: The 2560 Board is Not So Stupid Anymore

It's not just one bootloader, that's the problem. And there would be a lot of boards out there with older bootloaders.

Very true Nick, but crap, this has been going on for years, add this item to the test suite for every bootloader and get rid of the problem. Testing for this is so easy and simple that it can't even come close to comparing with the other problems normally tested for.

As for the boards already out there, the users can fix them if they have a good bootloader to put on them. Heck, you've come up with a method that works pretty well, all that's needed is a good bootloader somewhere it can be downloaded easily. There just isn't any excuse for something like this coming off the production line for any of the arduino boards anymore. Three years ago, maybe, but not now.

The problems I'm observing with my Arduino Micro, however, are not to do with the watchdog.

I'm a little surprised it's working so strangely, the only excuse I can give is that it is new and they are ironing out bugs.

That was released on Thursday, November 8th, 2012. So it's pretty new.

Yes, your problem may well be a brand new bug. New bugs are expected and have to be tolerated, I totally understand that. My tirade was only directed at the watchdog timer problem that has plagued us for years on various boards through many production runs and major modifications.

While we are at it, I would like to complain about the free() bug which causes a lot of heartache. And that is across all the supported platforms.

Help me, I know that free() will fracture memory and cause the board to run out. Is that what you're talking about? That particular problem of fragmentation is not only on the arduino, it's everywhere. I once had to write code for a unix system to recover that memory and pack the usage back down to reasonable, for an ATM strangely enough. Yes, I read your other post. As part of that project, I searched around and found out that that was a conscious decision back when it was being developed. It was either eat time tracking and keeping memory usage under control, or run fast and let it get out of hand. Remember how slow machines were back in the '80s? they chose fast.

Which meant, every night after midnight sometime, the ATM would pause, clean up memory and then continue. Took too long to reboot the darn thing and it was hard on the hardware to go through the entire boot up diagnostics on the depositor and dispenser for something like this.

No, I'm not talking about fragmentation. There is a bug in the library. Code that should work perfectly well (eg. allocating 10 bytes, freeing those 10 bytes, and then allocating them again) fails.

Right, that was the tool set using an older version of free(). I thought that was fixed in the later IDEs; that's what I get for assuming.

phthomps:
Hi,
Could you please tell me if its recommended/safe to run an Arduino micro 24/7 in a home environment?
So far I have 1 setup but would like to use 5 of them to control roller blinds in my house, my setup works as follows:

  • Arduino Micro (input power 12v from switching adapter vin/gnd)
  • Qik 2s9v1 to control 2 motors when activated(1 motor is on each blind), it also uses the same 12v power from the power supply
  • 2 reflectance sensors (only active when the motor moves to auto stop the blind)
  • 1 Infrared receiver

When not in use, the void loop performs some logic checks and is listening for an infrared signal (using IRremote libary)
Also, would it be better to use less voltage for the input or is this not important?
Thanks in advance for your help!
Paul

I have my home thermostat system running via Arduino along with remote temperature Arduino modules that all run 24/7 without issue. All have their own power source, the thermostat Arduino uses the furnace voltage supply and the remote modules plug into wall sockets. I use Teensy 2.0 instead of Arduino for size/power/price reasons. But, it's the same ATmega microcontroller so it will work the same.

I also have a few systems that block rooms for dogs via an ultrasonic transducer for both detection as well as ultrasonic alarm so it only bothers the dogs, not humans.

In both cases, zero problems running 24/7. Never a crash. Even working in solar power as some use such low current even household lighting could power the system.

Tim

Hi,
I tried the same test again as yesterday (with the WDT) but this time on my second Arduino Micro. It also showed the same symptoms where I couldn't upload anymore. Could it be possible that the ones I have use a different firmware or are from another batch?
In the mean time everything seems to be working fine without the WDT so i'll give it a go for few days.
It's really nice to hear that other people are seeing strange behavior with their micro boards so i'm happy that it's probably not damaged.
Nick, you mentioned that installing a corrected bootloader will fix it, do you know how I can do this or if a new one is available yet?

Regarding the Teensy, I picked up version 3 a fews days ago for a bit of fun (haven't tried it yet) but over here in Europe they cost quite a bit more than the arduinos.

Thanks to everyone for your support!