next topic »

[Reply #15 on:]

Hey, if the extended fuse is standard 0x05 then the Uno already has BOD enabled.
0x04=4,3V
0x05=2.7V
0x06=1.8V
0x07=disabled BOD
And then I actually changed from default 2,7V to 4,3V. I'm not sure if that is an improvement.

[Reply #16 on:]

I presume it's an improvement because the processor won't run at 2.7V at 16 MHz. In fact you can't run above 10 MHz at that voltage.

[Reply #17 on:]

Now all is clear to me, I wrote this summary to have all the information in one place and to share with you.

I wanted to have low voltage (brown-out) detection on my Arduino Uno R3 to prevent it from unexpected behaviour or even destroying my sketch when the 5V power supply drops below a certain level. I want to show how to correctly set the brown out detection. To set the brown-out detection a new bootloader with the setting must be burned to the Uno. I  have used 1 Arduino Uno to burn a bootloader to another Arduino Uno. The other Uno is used as an in-system programmer(ISP). Here's a description how to do that http://arduino.cc/en/Tutorial/ArduinoISP.

In the Arduino IDE (mine is 1.0.1) boards.txt contains bootloader settings of many different Arduino boards. On my computer the file is located here D:\programs\arduino-1.0.1\hardware\arduino\boards.txt. In that file you need to find the Uno.

Code:

##############################################################
uno.name=Arduino Uno
uno.upload.protocol=arduino
uno.upload.maximum_size=32256
uno.upload.speed=115200
uno.bootloader.low_fuses=0xff
uno.bootloader.high_fuses=0xde
uno.bootloader.extended_fuses=0x05
uno.bootloader.path=optiboot
uno.bootloader.file=optiboot_atmega328.hex
uno.bootloader.unlock_bits=0x3F
uno.bootloader.lock_bits=0x0F
uno.build.mcu=atmega328p
uno.build.f_cpu=16000000L
uno.build.core=arduino
uno.build.variant=standard
##############################################################

A change must be made to one of these lines to set the fuses of the Uno.

To find the fuse settings this fuse calculator is useful. http://www.engbedded.com/fusecalc. For Uno select ATmega328P. The second table shows that the brown-out detection (BOD) level is set with the extended fuse. Bits 0 to 2 are used to set the voltage level. Bits 3 to 7 are not used. Playing around with the calculator shows that 0x04 is 4.3V, 0x05 is 2.7V, 0x06 is 1.8V and 0x07 is disabled BOD. The datasheet of the ATmega328P shows the same BOD level coding.

This means that the default setting of 0x05 for the Uno that came with the IDE is 2.7V. So the Uno already has brown-out detection enabled. That's interesting, because the Arduino Uno runs on a 16MHz external crystal. The datasheet of the ATmega328P shows that at 2.7V the maximum frequency for safe operation is 10MHz. So at 16MHz the minimum voltage for safe operation must be set to 4.3V. So extended fuse must be set to 0x04.

You now learned that it useful to change the brown-out detection level for your Uno. Don't forget to save the boards.txt file, restart the IDE, burn the bootloader and then burn your sketch. Happy brown-out detecting!

[Reply #18 on:]

I presume it's an improvement because the processor won't run at 2.7V at 16 MHz. In fact you can't run above 10 MHz at that voltage.

On one of my homebrew pcbs, I can select Vcc=5V or 3.3V, and both Duemilanove and UNO chips run
fine at either voltage using a 16-Mhz xtal. I know the d/s curves indicate you can only run up to about
13.3-Mhz at 3.3V, but it seems to work fine at 16-Mhz [even though most people were recommending
against it on other recent threads - I'll just use it till it stops working, :-)].

Also, I just bought a couple of JeeNode modules this past week, and they interestingly include a 16-Mhz
resonator and the v.reg is a 3.3V part. And they've been selling commerically for a few years, so .... ???

[Reply #19 on:]

I think when I was testing power savings I cranked the voltage down and it kept working, and eventually stopped. No doubt under the recommended voltage.

But, operating out of spec, what can I say? You can't complain if it goes wrong.

[Reply #20 on:]

But, operating out of spec, what can I say? You can't complain if it goes wrong.

It's not running my pacemaker, so no worry there, LOL. If my robot stops or something, well, that's
his problem.

[Reply #21 on:]

I'm comming to this late and brown outs may be one of my problems, the mains here seems to be particularly dirty. Certainly I'm getting programme corruption.

I've just put a 9V alkaline battery (through a diode to prevent back feeding) onto the barrel plug as well as the custom mains PSU for the system (9v transformer 4 diodes and a 220microfarad capacitor) that is pluged into the 9V pin on the uno board. Its not elegant or a long term solution but should keep the thing alive and let me work out if its spikes or sags/brownouts that are causing the problem.

Is there a way of setting the fuse bits other than using another arduino??

Conversely does anybody know about the effects of voltage spikes on the 328 chip

[Reply #22 on:]

I think fuse setting has to be done in programming mode, which needs to be done via the ICSP interface, or a dedicated programmer. You can read fuses in an ordinary program. Example:

Code:

#include <avr/boot.h>

#define SIGRD 5

void setup ()
{
Serial.begin (115200);
Serial.println ();

Serial.println ("Signature");

byte sig;
  sig = boot_signature_byte_get (0);
  Serial.println (sig, HEX);
  sig = boot_signature_byte_get (2);
  Serial.println (sig, HEX);
  sig = boot_signature_byte_get (4);
  Serial.println (sig, HEX);

Serial.println ("Fuses");
byte fuse;
 
  fuse = boot_lock_fuse_bits_get (GET_LOW_FUSE_BITS);
  Serial.println (fuse, HEX);
  fuse = boot_lock_fuse_bits_get (GET_HIGH_FUSE_BITS);
  Serial.println (fuse, HEX);
  fuse = boot_lock_fuse_bits_get (GET_EXTENDED_FUSE_BITS);
  Serial.println (fuse, HEX);
  fuse = boot_lock_fuse_bits_get (GET_LOCK_BITS);
  Serial.println (fuse, HEX);
}

void loop () {}

You can get a $10 programmer board like the USBtinyISP or similar. You don't need another Arduino as such.

Certainly I'm getting programme corruption.

Could be a program bug.

[Reply #23 on:]

Thanks for the info on the USB program loader. I've now got a copy of the Arduino cookbook which also mentions such things.

As to programme bugs, then if thats the case it must be in the libraries somewhere, but the problem of programme corruption is random in its symptoms but it happens after the mains has a funny five minutes - but not always.

As to the standard Uno having BOD at a lower voltage than the point that the chip becomes unstable, what were the people who design and build the things thinking of - not very good engineering in my book.

[Reply #24 on:]

Funnily enough I just read another thread yesterday where someone complained that the 4.3V brownout made it too unstable on a 5V supply and recommended lowering the threshold. On the face of it, you would think 4.3V would be OK when running from 5V.

[Reply #25 on:]

Funnily enough I just read another thread yesterday where someone complained that the 4.3V brownout made it too unstable on a 5V supply and recommended lowering the threshold. On the face of it, you would think 4.3V would be OK when running from 5V.

Indeed it should be, maybe it's the 5V supply that's not stable. I've increased the BOD level on a couple projects to 4.3V because I want the µC to go into reset ASAP when the power starts failing. Works fine near as I can tell. I have noticed that some of these inexpensive plug supplies (wall warts, AC/DC adapters) do some interesting things when they're unplugged. I have some where the voltage falls, then there is a quick blip where it increases again. This is one of the reasons I tried the 4.3V BOD level.

[Reply #26 on:]

Does anybody know what happens with things like the ethernet shield when the BOD activates?
On my current project the web servercode or the shield seems to stop working (IE comes up with a connection problemand wont display the pagefrom the SD card) even though there is a backup battery.
Ironically the SD card keeps on recording data every 10 min, though it ocasionally misses a beat.
The only way to get communications going again seems to be a 'power off' reset!

[Reply #27 on:]

When the BOD activates, as far as I know the processor enters a reset state. However this doesn't mean any attached peripherals reset. Nor does it mean the reset pin changes state (as far as I am aware).

So to effectively recover other peripherals you would have to (in setup) make them reset, if possible.

[Reply #28 on:]

The brown-out detector can be set for 1.8, 2.7 or 4.3V via the extended fuse byte. Arduino Unos are set for the 2.7V level. I'm currently working on a project where it was beneficial to change it to 4.3V.

Isn't 2.7V a bit low? At 16 MHz the processor requires 3.78V. So it would become unreliable before the brown-out reset kicked in.

True, but 4.3V was probably deemed to close for comfort for general use (Arduino's can run off 3 alkaline cells nicely, which is
4.5V...) 

At room temperature it seems you can run a 328 or 168 Arduino at 3.3V and 16MHz reliably, its at higher termperatures that it will
actually fail  (the graph in the datasheet doesn't give temperature dependence though, this is anecdotal data only, but CMOS is
faster at lower temperatures).

[Reply #29 on:]

Ive been pushing the problems of the unpredictable malfuncuntion of my Uno/ethernet shield combination around for some time now (see above) and I thought I had cured the problem by replacing the 220uF smoothing capacitor on the PSU with a 4700uF one!, (Jack Christensen suggested the PSU might be the problem).

However I'm still intermitently getting some sort of hang on the ethernet, not as frequent but it still happens. IE comes back with a cant connect but I can go into CMD and ping the IP address and get a responce with no losses.

Also sometimes the set up stops recording data to the SD card.

Given that we have fluky mains here I keep comming back to the BOD function and the interaction of the Uno and the W5100 chips. I've discovered that the uno chip does not pull the reset line low when it activates so there is no reset of the W5100 on brown out.

Now if the 5V arduino resets the brown out may not be long enough for the W5100 to actually switch off which could leave it in an indeterminate state when the arduino wakes up again. This could also be the reason for lossing the SD card data if the SPI lines are screwed up

Nick Gammon suggests forcing the ethernet shield to reset when the arduino BOD activates, but Ive not found any circuits or software for this and there is no reset output on the processor. Does anybody hsave any advise on this.

I've also looked at Issue 888 which has veen solved in version 1.0.3 which I could incorporate with an update but I dont see that this would stop the problem