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 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?

Yes, just follow my instructions up to programming the bootloader. Leave all other fuse settings in place and set just the BODLEVEL fuse to the desired level, then click on the Program button. You will see the result below, if it's OK, you're done and you can close that window and AVR Studio.

... explanation.

In some conditions like voltage spikes it is possible for the flash or EEPROM memory to get corrupted, especially id the BOD fuse is not set.

So add a big cap on the power input for the logic it may help.

Oh, man. You are blowing my mind. I've never had to dig into the internals of the Arduino IDE. Fuses? WTF are fuses?

I did some reading, and I see this is set in the boards.txt file in the hardware sub-folder of the Arduino install. I also see that the Brown Out Detection (BOD) settings for the ATMEGA328p (which is what I'm using) were moved to the extended_fuses section. I have this in my boards.txt file:

atmega328.bootloader.extended_fuses=0x05

I'm seeing inconsistent or at least confusing info on what values to use for the different BOD levels, and also about what the default setting is for the Arduino.

The BOD levels are:

  • VCC=4.3 V
  • VCC=2.7 V
  • VCC=1.8 V
  • VCC=Disabled

I tried the 'Fuse Calculator' that I saw referenced in several places. None of the above BOD settings results in an extended_fuses setting of 0x05 as I have in boards.txt. The fuse calculator site notes that:

some numerical values refer to fuses containing undefined bits (set to '1' here). Depending on the target device these fuse bits will be read either as '0' or '1'.

I interpret that to mean that there are some 'don't care' bits, and so the value they recommend might not be identical to the value I have set, but it would result in the same fuse setting. However, I still don't know what my value means, which is the thing I'm trying to figure out.

Some additional messing around with that site leads me to believe that the 0x05 default BOD setting for the 328p is at 2.7V.

The uServotino has a voltage regulator supplying the chip, and good caps everywhere on the board. So I'm not convinced this is a brown out issue. However, I did learn a lot by digging into this, even if it is not the root cause. Thanks for the tip!

... I'm no AVR expert by any means.

However extended fuses set to 0x05 which if you input by hand in the fuse calculator shows the right value for BOD level 1 so it should be set to 2.7 volts. I'm sure the explanantion is with the 5 bits left unset since only three are used in the register.

When I posted I was thinking on the following setup based on my assumptions:

- you power the board from a power source probably batteries?

- the same power goes to the motors too?

- voltage maybe 6 V?

I this case it can be possible that a voltage drop occurs when powering up/resetting and since BOD is set to 2.7 V the spike can go as low as that, which is a lot under VCC ... so it could cause the weird stuff.

I forgot to mention the fuses are set when programming trough ISP so the value set in the boards file is used when the bootoloder is burned trough some ISP programmer only. In this case I thing Ro-Bot-X used the same values when loading the bootloader so it should be the same.

The voltage regulator will not help in my assumption above it has it's own voltage drop of about 1.5 V so it's pretty close to it's limits.

So if I'm right the solution would be in a 100 to 470 uf electrolitic cap put on the power source before the regulator ...

These continue to be good thoughts. I came to the same conclusion on the AVR settings. I think it is at 2.7V.

I am using 4xAA alkaline batteries, as you guessed. However, the voltage regulator is a Low Drop Out (LDO) type. It should be able to operate down to within 0.5V of the regulated value. Ro-Bot-X included 220uF caps on both input and output of the regulator. There are also 10uF and 0.1uF caps on the out pins to help keep the noise down.

Still, you might be on to something. The most obvious culprit to me is the battery holder, which has a crack in it. I think it might be losing contact unpredicably, and maybe that is causing power weirdness. I will correct that and see if the problem reoccurs.

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?