I'm reasonably new to Arduinos but recently became aware of the 2S delay at boot up. It seemed optiboot has a delay in mS so attempted to load it into a ProMini 5V 16MHz.
I'm using a UNO-R3 as the ISP and while I've tried several approaches (all with the same result) I'm currently sticking with Minicore. After burning the bootloader the ProMini shows 2 quick flashes every second which implies to me the bootloader has installed correctly.
Is this assumption right?
The problem is after burning optiboot, using my FTDI programmer it fails to upload sketches (i'm just using the Blink sketch for testing purposes). The verbose output is as follows:
Arduino: 1.8.10 (Windows 10), Board: "ATmega328, Yes (UART0), EEPROM retained, 328P / 328PA, BOD 2.7V, LTO enabled, External 16 MHz"
Sketch uses 880 bytes (2%) of program storage space. Maximum is 32256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.
C:\Users\Scott Wilson\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino18/bin/avrdude -CC:\Users\Scott Wilson\AppData\Local\Arduino15\packages\MiniCore\hardware\avr\2.1.3/avrdude.conf -v -patmega328p -carduino -PCOM10 -b115200 -D -Uflash:w:C:\Users\SCOTTW~1\AppData\Local\Temp\arduino_build_984247/Blink.ino.hex:i
avrdude: Version 6.3-20201216
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Users\Scott Wilson\AppData\Local\Arduino15\packages\MiniCore\hardware\avr\2.1.3/avrdude.conf"
Using Port : COM10
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xbd
avrdude done. Thank you.
I know the hardware setup is correct as I can restore the original ProMini bootloader using the same process and upload sketches via the FTDI programmer. I can also upload a sketch to the ProMini (without a bootloader) via the UNO-R3 using "Upload Using Programmer" option successfully.
I've read many posts related to this topic but unfortunately none of the solutions have worked for me. I've also tried installing the IDE & Minicore on another PC which produced the same failure.
I'm hoping someone out there may be able to offer some advice please.
Weird. The default bootloader on the Mini is optiboot and it takes up more memory than the non-optiboot bootloader on the Pro Mini?!? Also uses a different baud rate.
mini.name=Arduino Mini
mini.build.board=AVR_MINI
## Arduino Mini w/ ATmega328P
## --------------------------
mini.menu.cpu.atmega328=ATmega328P
mini.menu.cpu.atmega328.upload.maximum_size=28672
mini.menu.cpu.atmega328.upload.speed=115200
mini.menu.cpu.atmega328.bootloader.high_fuses=0xd8
mini.menu.cpu.atmega328.bootloader.file=optiboot/optiboot_atmega328-Mini.hex
pro.name=Arduino Pro or Pro Mini
pro.build.board=AVR_PRO
## Arduino Pro or Pro Mini (5V, 16 MHz) w/ ATmega328P
## --------------------------------------------------
pro.menu.cpu.16MHzatmega328=ATmega328P (5V, 16 MHz)
pro.menu.cpu.16MHzatmega328.upload.maximum_size=30720
pro.menu.cpu.16MHzatmega328.upload.speed=57600
pro.menu.cpu.16MHzatmega328.bootloader.high_fuses=0xDA
pro.menu.cpu.16MHzatmega328.bootloader.file=atmega/ATmegaBOOT_168_atmega328.hex
Do you still have the board type set to "pro mini" after uploading the new bootloader, or are you using one of the minicore board types?
In theory, after having Optiboot installed, a pro-mini should behave like a "new Nano" or Uno. Try setting the board type to one of those and seeing if the upload works...
After uploading the bootloader I have the board type set to the minicore Atmega328.
I've tried selecting UNO and Nano as you suggest but with the same results as before.
Interestingly after the bootloader is loaded the FTDI programmer has the 2 Tx/Rx LEDs dimly lit and there's no heartbeat on the Promini.
I've managed to run avrdude from a cmd prompt to interrogate the Promini with optiboot loaded.
Two things have shown up: firstly I had to set the baud rate to 19200 otherwise it produced the same sync errors I experienced with FTDI programmer. Secondly the Hi fuse byte is set to $DE and according to the Atmel datasheet setting bits 1&2 high allocates 256 bytes for the bootloader?? My understanding is optiboot occupies 512 bytes.
I'm out of my depth from here. Hoping someone may be able to tell me if this is likely to be causing corruption to the bootloader.
Also what do I need to do to change the hi fuse byte in optiboot to say $DA. Any advice greatly appreciated.
This doesn't need to match the baud rate used by the Optiboot bootloader because you are communicating directly with the microcontroller via the ISP programmer, and so the bootloader is not involved in the chain at all.
I have finally resolved this mystery which came down to a hardware issue. I ordered a new FTDI programmer and when I connected it everything worked as expected (able to upload sketches with optiboot installed). On the faulty FTDI I found the DTR pin floating at 2.5V which affected the reset pulse to the Promini.
Loading the Promini with its original bootloader the DTR pin floated to 4.5V (still low but enough to provide an appropriate reset pulse) hence everything appeared ok until optiboot was loaded. I'm assuming the baudrate somehow altered what the DTR floated to.
Thanks to everyone who replied throughout this thread.
