Let's Make Robots!

Arduino project losing its mind

I'm using Ro-Bot-X's uservotino for my Venux robot. I recently had a problem where the sketch (program, for all you non-Arduino types) disappeared on me. The board would power up fine, but nothing would happen. Then I upload the sketch again and everthing is fine.

I thought it was an isolated incident, but it just happened again! Any thoughts on what would cause an Adruino to lose its mind?

EDIT: The issue turned out to be with the Brown Out Detection (BOD) settings on the Arduino bootloader. The BOD defined in the bootloader was disabled. When the power to the Arduino dips too low, it can wind up corrupting memory, including the stored code. The BOD feature tells the processor to reset if the power dips below a selectable threshold. Since my chip didn't have a BOD threshold set, I lost the program code.

To change the BOD setting, I'll need an ISP programmer, which I don't currently have. So I'll probably just live with this for now. Thanks for all the help figuring out what happened!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I had the same issue with an Arduino clone I designed and it turned out to be a bunked resonator.  I would load a sketch and it would run for a while and then disappear.  I found it after hooking up a Oscope and checking the timing of the resonator.  May not be what is causing your problems but, it may be a starting point to look at the timing of the crystal on the uservotino.  \0/

Thanks, I'll look into that. I'm on a beta version of the uservotino. The resonator had to be installed with a gap between the board and the resonator, or it would short to the two caps on either side. Ro-Bot-X corrected this in subsequent board layouts. Your post made me wonder if I've developed a cold solder joint or something. Maybe this is a good excuse to break out my mini o-scope. ; j

Gah. Silly me. Xprotolab mini-oscope is waaaaay too slow to examine the a 16MHz clock signal. Someday I'll get a real o-scope.

You have a Xprotolab Mini o-silly-scope? We have to talk! I've been wanting one for a while. What do you think about it? It's slow, but besides that, is it worth the price?

Well, the price was right, less than $50 with shipping. Lead time and shipping took many weeks. It's tiny, which could be a plus for some purposes. It certainly works, and it is an improvement over a no-scope. ; j

However, I now wonder if I could have picked up a used real o-scope for 2 to 4 times the cost and been better off. Getting a little bit of a good thing makes me want more of it.

Final word: I'm glad I have it, but I'll probably buy a real scope when I can afford it.

Ok, thanks. I think I'll do with the scope I have now (60s Heathkit, 5MHz) even though it isn't that great for too much, and then save up for something bigger. Thanks!

IG, here is how I set up the fuses in a blank microcontroller and upload the Arduino bootloader:

In AVR Studio 4, I click on Connect, select my ISP programmer and Auto COM port, (while the programmer is actually connected to the µBotino board and the board is powered by a USB-serial cable - so I have both programmers connected to the board at the same time, just to avoid hooking up batteries), then a window "STK 500 in ISP mode" appears. I click on the Main tab, select the ATmega328P microcontroller, click on Read Signature to make sure I have a correct connection with the microcontroller. Then, I click on the Fuses tab and I get the following manufaturer set fuses:

EXTENDED: 0xFF
HIGH: 0xD9
LOW: 0x62

BODLEVEL is set to Brown-out detection disabled  - I don't touch this.

I change the following fuses:

BOOTSZ - from 2048 to 1024 words
BOOTRST - check
CKDIV8 - uncheck
SUT_CKSEL - Ext. crystal 8.0... (the last position on the list)

The fuses values change to this:

EXTENDED: 0xFF
HIGH: 0xDA
LOW: 0xFF

I click on the Prgram button to write the fuses, then go to the next part.

Then I click on the Program tab, look in the Flash section and browse for the ATmegaBOOT_168_atmega328_pro_8MHz.hex file and click on Program.
To finish up I click on the Lock Bits tab, click on the BLB1 and choose from the list LPM and SPM prohibited in Boot Section and the LOCKBIT fuse changes from 0xFF to 0xFF. I click on Program and the bootloader is now protected by accidental programming until you do a Erase Device from the Main tab.
After all this, I disconnect the ISP programmer, go to Arduino and using the USB-serial cable I upload the Blink scketch to verify if all went well.

Ah! Well that explains it. If BOD is disabled, the symptoms fit what TinHead described. I assumed (incorrectly) that you would go with the BOD settings Arduino uses as the default.

I might want to re-flash the chip with a BOD level of 4.3V. If it goes below that, something is definitely wrong, since the regulator should keep things at 5V unless the battery level drops.

I suspect a bad solder joint to the crystal or accidental shorting it for the code corruption. It would be nice to do a Read code just to see if the code in the flash was indeed corrupted. I never did a Read, but I heard it is possible. I did not add BOD functionality just in case one might use the chip with 3.3V (I guess a 2.7V level would be fine) but also because I wanted to get the same fuse settings as if the bootloader is uploaded within Arduino IDE. I might be wrong, but so far it worked fine. Oh, one more thing, you can change the fuses without altering the bootloader or do a Erase Device, except for the lock bits. If you use the BOD, any time your voltage drops below the set level, the micro is reset, so it will be a good idea to have it beep (in a special way) in the Setup function, to check if the micro was reset. For instance, if you're using a lot of servos, at start up the voltage might drop below the BOD level and you will be wondering why your program does not start.

I can change the fuses for the BOD settings without changing the bootloader? Does that mean I don't have to reflash the device?