Setting fuses, changing boot loader, lose comms to pro mini

I have been searching for an answer to my problems but have become more confused as I have searched!
I am using a arduino pro mini (16mhz, 5v) board. I have removed the regulator and led to run off of battery power (3v) I am wanting to implement all the available power saving techniques to allow my design to last as long as possible on battery power.
I have several questions that have been asked many times before but the answers I have found either does not fit my needs specifically or they do not seem to work when I attempt to implement them!
I have created a new entry in boards.txt as follows:

############################################################## Pro Mini (3v, 2MHz)


pro328p.bootloader.lock_bits=0x0F (3V, 1 MHz) 30720
  1. If I were to implement the CKDIV8 fuse would that allow the atmega328 to operate down to 1.8v?
  2. if the CKDIV8 fuse is selected, should this affect the baud rate? Should it affect the boot loader? I am having problems communicating after setting this up and it seems the mini does not actually run the sketch with the new fuse values.
  3. If I were to implement the internal 8Mhz clock and use the CKDIV8, I have the same questions as 1 and 2???
  4. The default settings for the mini calls for the boot loader atmega/ATmegaBOOT_168_atmega328.hex, is there an optiboot available for the mini? maybe optiboot/optiboot_atmega328.hex? (I set this in my boards.txt file)
  5. if there is an optiboot boot loader available, what would the new lfuse setting be to accommodate the smaller boot loader? Should I be able to get more programing space?

My current problem is that when I attempt to upload the boot loader and burn new fuse values, my code does not work, (it works fine before attempting this)
I need to reduce the frequency to get lower voltage performance.

I am using an arduino uno to program the boot loader. And changing things does not keep me from accessing the board to reset it if need be.
I am using a USB 2.0 To TTL 6Pin CH340G Converter to upload the sketches.

Thanks in advance for any/all your help.

  1. the CKDIV8 fuse enable the "divide by 8" setting, and makes the CPU run at 1 MHz instead of 8. According to the datasheet you can't run it at more than 4 MHz at 1.8v. Since the internal clock is only dividable by 8, you're stuck with 1 MHz.

  2. Since the clock is 8 times slower, it affects the baudrate BIGTIME! You need a bootloader thats compiled for a 1 MHz clock.

  3. Nor sure if I understand the question. I guess you'll find the answer above

  4. Yes, Optiboot is available. You should really check out MiniCore (github link), which takes care of all these problems for you. All you have to do is to select your preferred clock speed, and the correct (optiboot) bootloader is automatically selected.

  5. With MiniCore the bootloader is only occupying 512b (instead of 1024b as ATmegaBOOT does), and the low fuse is corrected, so this isn't a problem :slight_smile:

Thanks Hansibull,

your mini core seems to have worked great! I have been fighting this for sometime now and it worked as soon as I used your mini core!

I have another question, what needs to change in the boot loader to operate with the external 16MHz crystal and CKDIV8 set (2MHz)?

So I am currently using your ATmega328 profile, 328P, BOD 1.8v, 1MHz internal.

After that my code seems to have stopped reading my DHT22 temp/humidity sensor. Is there something in your core that may have caused it to stop working (maybe too slow now?? I am not sure)

Again, thanks for your help.


CKDIV8 fuse determines the initial value of the CLKPS. So you can run an ATmega328P on a Pro Mini at 1.8V by setting the CKDIV8 fuse and using the 16MHz crystal. You will also need to disable the BOD (brown out detection) fuses so it will run at the low voltage. It will run at 2MHz, which is in the correct range for 1.8V operation. You can compile a version of Optiboot that runs at 2MHz and 9600 baud for uploads.

Initial value of the clock division in the fuse, right? Well, that means: in the setup of your sketch you can further alter the CLKPS setting to divide by 4, bumping the speed up to the full 4MHz allowed for 1.8V operation.

It's hard to see LEDs glowing when switched by 1.8V, they barely glow at all, so keep that in mind if you are trying to run the blink sketch to verify operation. Having some bidirectional level converters handy is, well, handy...

Bottom line is it works fine at 1.8V with 16MHz crystal, clock frequency divided by fuses and code to the speed you like.

More info than you can shake a stick at:

Added note: you can also add CLKPS adjustment in the Optiboot bootloader right before the Adaboot modification, so right at the beginning of the bootloader (or before it quits the bootloader to run the user program) it switches the clock to divide by 4. Then you would not need to worry about making the adjustment in the setup of each sketch, the board would just run as if it has a 4MHz crystal. I have done that before. You could then probably run the bootloader faster than 9600 baud. But really 9600 baud is fast enough for sketch uploads.

Thanks dmjlambert,

I will try some of the things you put in the link you included as well. It seems like that is the way to go.


Ok, I have gone with using the standard 16Mhz Arduino Pro Mini boot loader and then implemented the code

  #if F_CPU == 16000000

When this executes, I am no longer able to read my DHT22 sensor - It returns "nan"

 * Read Temp from DHT22 sensor
void readDHTtemp(float *TH)

  TH[0] = dht.readHumidity();
  TH[2] = dht.readTemperature(); // Temp in C
  TH[1] = convertCtoF(TH[2]);


What else do I need to do so that it works using 4Mhz clock speed??

Thanks in advance.


My Thoughts:

I suggest step back and do something simpler first. Such as make sure the blink sketch blinks your LED at the rate you expect it to. That will ensure your sketch was compiled for the same clock frequency that the processor is actually running at.

If you look at the boards.txt file, each board has f_cpu set to the frequency, for example f_cpu=16000000L. When you select a board, and compile a sketch, this tells the compiler how fast the processor it is compiling the sketch for will be running. It also fills the F_CPU variable with the same frequency value.

The frequency at which the processor is actually running is determined by the crystal attached and whether or not you are dividing the frequency with the CLKPS setting in your sketch and/or with the CKDIV8 fuse.

That's 2 things: the frequency the sketch was compiled for, and the actual speed the processor is running at. You need to make sure those 2 things match.

If you upload the blink sketch and it is set for one second on, one second off, one second on, etc. and you see it flashing at the wrong rate, that is an indication you have not matched those 2 things.