A pro Mini has no USB interface, it is just a MCU, a crystal and a reset button. You can program it both over SPI or Tx/Rx using avrdude, avrdudess (GUI) combined with USBTinyprogrammer or USB-ASPprogrammer; or with Arduino as ISP. Why would you need a bootloader?
Typically a Pro Mini will be used with a separate USB-serial breakout board or cable. Just as with any other board, the bootloader is necessary to upload via serial (Tx/Rx). The bootloader is not necessary (and in fact will be erased) if you are uploading via ISP.
pert:
Typically a Pro Mini will be used with a separate USB-serial breakout board or cable. Just as with any other board, the bootloader is necessary to upload via serial (Tx/Rx). The bootloader is not necessary (and in fact will be erased) if you are uploading via ISP.
Hi pert, I uploaded a program to a pro mini with isp using USBtiny-programmer and avrdude commands. Afterwards I uploaded the same program using Arduino IDE and a "USB to Tx/Rx serial programmer" (CP2102): does the bootloader then automatically get installed by Arduino?
No, it's not automatically installed. You need to do Tools > Burn Bootloader with the programmer connected to reinstall the bootloader.
Hi pert, but if the bootloader is erased as you stated earlier when using ISP and avrdude (I did not disable flash erase) how is it possible I could use Rx/Tx afterwards without issues?
I was referring to Sketch > Upload Using Programmer. Apparently the upload you did using avrdude directly did not erase the bootloader and so it is still present on your Pro Mini.
I did a flash and eeprom erase on the 168P and loaded the latest optiboot_atmega168.hex (written May 30 2015, downloaded from Releases · Optiboot/optiboot · GitHub).
After download (using a USBtinyISP v2.0 board and avrdude commands) the pro mini board LED starts to flash in three times in 50/50 dutycycles with 0,5 seconds period per flash. Then 1,5 seconds pause, then resume.
Is this normal behavior on this 168P after bootloader download (no other program loaded)?
When I download a "normal" program it executes continuously and flawlessly.
Subsequently I try to use the Arduino IDE (instead of avrdude command line) to burn a bootloader (which one I do not know, it says nowhere?). I use a USBTiny-programmer properly configured and recognised by my pc.
Subsequent trials:
Trial 1:
Programmer (Arduino IDE): "USBtinyISP SLOW (ATtiny)": error burning bootloader. Signature found 1e940b, signature expected 1e9406. The avrduded expects to see a Atmega168 but there is an Atmega168P in my pro mini. The boards.txt associated with the optiboot folder has an Atmega168P included!
Trial 2:
This time with "USBtinyISP (slow)": same issue with 168 versus 168P
Where do I need to adjust the boards.txt file (or other files?) to eliminate this signature error?
And I still do not understand the need for a bootloader on a board that has no USB (Pro Mini,..).
An interesting discussion (https://www.researchgate.net/post/what_is_a_boot_loader_in_avr_microcontroller) refers to the avr bootloaders as "flashloaders", ie for a Digistump: there I see the use for a bootloader. But why on a Atmega controller, except if you want to do prototype testing? Where do I miss something?
Without the bootloader, it is impossible to upload a sketch using Tx/Rx - only via ISP (or parallel programming, which is much more awkward). Uploading via serial is generally considered more convenient.
brice3010:
and loaded the latest optiboot_atmega168.hex (written May 30 2015, downloaded from Releases · Optiboot/optiboot · GitHub).
When you post links on the forum please use the chain links icon on the toolbar to make them clickable.
brice3010:
Subsequently I try to use the Arduino IDE (instead of avrdude command line) to burn a bootloader (which one I do not know, it says nowhere?).
Check the bootloader.file value in boards.txt.
brice3010:
Where do I need to adjust the boards.txt file (or other files?) to eliminate this signature error?
Just select Tools > Processor > ATmega168p.
brice3010:
And I still do not understand the need for a bootloader on a board that has no USB (Pro Mini,..).
Once you attach your "USB to Tx/Rx serial programmer" (CP2102) to the Pro Mini it has USB in the same way an Uno or Mega does. The fact that there are two modules connected together makes no difference, the wiring is the same. The microcontroller doesn't inherently have any way to be flashed via serial. It's necessary to have some code running on the microcontroller to receive the data coming in over serial and then store it in the flash memory. That's what the bootloaders you'll typically find on the Arduino do. There are other bootloaders available that accept data from other sources, such as TFTP or an SD card.
Now I understand!!
pert:
When you post links on the forum please use the chain links icon on the toolbar to make them clickable.
Ok
pert:
Check the bootloader.file value in boards.txt.
Found that; see right below.
pert:
Just select Tools > Processor > ATmega168p.
I did.
But I checked the associated boards.txt and found there is no "P" for the 168. I changed the "168" to "168P" wherever it shows in that section.
Then I discovered that the bootloader that this "168" section refers to is the diecimila one.
Then I looked up the possible alternatives in the ..\bootloaders\atmega\ folder and it shows the following:
ATmegaBOOT_168_atmega328.hex
ATmegaBOOT_168_atmega328_pro_8MHz.hex
ATmegaBOOT_168_atmega1280.hex
ATmegaBOOT_168_diecimila.hex
ATmegaBOOT_168_ng.hex
ATmegaBOOT_168_pro_8MHz.hex
Which one should I choose to be used with the 168P 5V 16MHz?
And which one for a 168P 3.3V?
And why would frequency matter in the bootloader (the frequency can be reduced with fusebits regardless of the crystal frequency?)?
And why not copy and use optiboot bootloader in the atmega folder?
pert:
Once you attach your "USB to Tx/Rx serial programmer" (CP2102) to the Pro Mini it has USB in the same way an Uno or Mega does. The fact that there are two modules connected together makes no difference, the wiring is the same. The microcontroller doesn't inherently have any way to be flashed via serial. It's necessary to have some code running on the microcontroller to receive the data coming in over serial and then store it in the flash memory. That's what the bootloaders you'll typically find on the Arduino do. There are other bootloaders available that accept data from other sources, such as TFTP or an SD card.
That is clear!
Thank you.
brice3010:
But I checked the associated boards.txt and found there is no "P" for the 168. I changed the "168" to "168P" wherever it shows in that section.
You said you're using the optiboot v6.2 package so it's right here:
optiboot32.menu.cpu.atmega168p.build.mcu=atmega168p
brice3010:
Then I discovered that the bootloader that this "168" section refers to is the diecimila one.Then I looked up the possible alternatives in the ..\bootloaders\atmega\ folder and it shows the following:
ATmegaBOOT_168_atmega328.hex
ATmegaBOOT_168_atmega328_pro_8MHz.hex
ATmegaBOOT_168_atmega1280.hex
ATmegaBOOT_168_diecimila.hex
ATmegaBOOT_168_ng.hex
ATmegaBOOT_168_pro_8MHz.hex
Again, I'm confused, what happened to you using the optiboot package? I think you need to explain what you're trying to do.
brice3010:
And why would frequency matter in the bootloader (the frequency can be reduced with fusebits regardless of the crystal frequency?)?
Because it has to get the baud rate right for the serial upload to work. If the MCU is running at a different frequency than the bootloader was compiled to expect then the baud rate won't match between avrdude sending and the bootloader receiving and the upload will fail. Actually if you look at the optiboot package's boards.txt you'll see they used a trick to use the same bootloader for 8 MHz and 16 MHz by changing the baud rate:
# For 8MHz using the internal RC Oscillator, we adjust fuses, use the same
# bootloader binary, and halve the upload rate.
#
So the bootloader was compiled to communicate at 115200 baud on a 16 MHz MCU but if the clock is actually 8MHz the boards.txt upload.speed value must be set to 57600 instead.
brice3010:
And why not copy and use optiboot bootloader in the atmega folder?
I don't understand what you mean by this.
pert:
You said you're using the optiboot v6.2 package so it's right here:
optiboot/optiboot/boards-1.6.txt at v6.2 · Optiboot/optiboot · GitHuboptiboot32.menu.cpu.atmega168p.build.mcu=atmega168pAgain, I'm confused, what happened to you using the optiboot package? I think you need to explain what you're trying to do.
I installed optiboot using USBtinyISP in conjunction with avrdude command line.
Next I wanted to try installing a bootloader using USBtinyISP in conjunction with the Arduino IDE. That is where I hit trouble: incorrect device signature.
..and subsequent issues with "where is the bootloader file", "boards.txt does show bootloader lines with amongst others the diecimilia",..
pert:
Because it has to get the baud rate right for the serial upload to work. If the MCU is running at a different frequency than the bootloader was compiled to expect then the baud rate won't match between avrdude sending and the bootloader receiving and the upload will fail. Actually if you look at the optiboot package's boards.txt you'll see they used a trick to use the same bootloader for 8 MHz and 16 MHz by changing the baud rate:# For 8MHz using the internal RC Oscillator, we adjust fuses, use the same
# bootloader binary, and halve the upload rate.
So the bootloader was compiled to communicate at 115200 baud on a 16 MHz MCU but if the clock is actually 8MHz the boards.txt upload.speed value must be set to 57600 instead. I don't understand what you mean by this.
Ok, that I understand now.
And what if I use DIVCLK8 and run the mcu at 2 MHz?
brice3010:
And what if I use DIVCLK8 and run the mcu at 2 MHz?
Then you either need to compile the bootloader for 2 MHz or adjust the upload.speed value in boards.txt to compensate.
pert:
Then you either need to compile the bootloader for 2 MHz or adjust the upload.speed value in boards.txt to compensate.
Great! If I understand correctly, I need to change:
pro.menu.cpu.16MHzatmega168.upload.speed=57600
to, for example,:
pro.menu.cpu.8MHzatmega168.upload.speed=9600
..or should I also change in the last line the "8" to "2" ?
Heck, I feel the need for a course on "boards.txt" writing 
pert:
The bootloader is not necessary (and in fact will be erased) if you are uploading via Sketch > Upload Using Programmer > ISP.
Hi all
could someone please confirm (to be ensure) when we upload sketch via ISP programmer (USBasp also?) then bootloader will be erased ?
I first time heard this
I can con
alexblade:
Hi allcould someone please confirm (to be ensure) when we upload sketch via ISP programmer (USBasp also?) then bootloader will be erased ?
I first time heard this
Yes, that is correct. Using an external programmer overwrites the bootloader.
BJHenry:
Using an external programmer overwrites the bootloader.
when you say overwrites , are you mean will be replaced by new one or just will be erased completely ?
and last question for understanding:
step 1. lets say we have PRO MINI board with bootloader and we upload sketch using FTDI converter (via Rx, Tx pins)
step 2. after that we upload another sketch using USBasp
step 3. now we want again upload another sketch with FTDI converter. will we be able to do this?
alexblade:
when you say overwrites , are you mean will be replaced by new one or just will be erased completely ?
There will no longer be a bootloader on the Micro.
alexblade:
when you say overwrites , are you mean will be replaced by new one or just will be erased completely ?and last question for understanding:
step 1. lets say we have PRO MINI board with bootloader and we upload sketch using FTDI converter (via Rx, Tx pins)step 2. after that we upload another sketch using USBasp
step 3. now we want again upload another sketch with FTDI converter. will we be able to do this?
After Step 3 you will need to use an external programmer to upload the bootloader again. Step 2 will have removed the bootloader.