search

stefanrueger / urboot

Small AVR bootloader using urprotocol
GNU General Public License v3.0
55 stars 8 forks source link

Autobaud does not work on one ATmega328P board under Windows #5

Closed mcuee closed 1 year ago

mcuee commented 1 year ago

Interestingly I have a Arduino Nano clone with CH340 and Atmega328P (5V, 16MHz). It works well with 115200bps and even 1000000bps urboot hex file (tested with the variant (tested with ee_led+b5_fr_ce_ur_vbl) but not working with the autobaud firmware (no matter which baud rate I try). Kind of strange.

The autobaud FW works fine with my Uno Clone (ATmega328P, 5V, 16MHz) and Mega2560 Clone (ATmega2560, 5V, 16MHz).

Maybe this is not a real issue but rather board specific.

mcuee commented 1 year ago

Run log:

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c usbasp
 -p m328p -U .\atmega328p_16mhz_1000000bps_ee_led+b5_fr_ce_ur_vbl.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock
 -P COM10 -p m328p -b 1000000 -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jpr-c vector 25 
(SPM_Ready) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c usbasp
 -p m328p -U .\atmega328p_16mhz_115200bps_ee_led+b5_fr_ce_ur_vbl.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock
 -P COM10 -p m328p -b 115200 -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jpr-c vector 25 
(SPM_Ready) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c usbasp
 -p m328p -U .\atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock
 -P COM10 -p m328p -b 115200 -xshowall
avrdude_pr1171v6 warning: attempt 1 of 20: not in sync
avrdude_pr1171v6 warning: programmer is not responding; try, eg, -xdelay=200
avrdude_pr1171v6 warning: attempt 2 of 20: not in sync
...
avrdude_pr1171v6 warning: attempt 20 of 20: not in sync
avrdude_pr1171v6 error: unable to open programmer urclock on port COM10

avrdude_pr1171v6 done.  Thank you.
mcuee commented 1 year ago

BTW, the autobaud FW seems to work pretty well for the ATmega2560, tested with some random baud rate.

Some do not work (300000, 600000, 800000, 900000; 120000, 160000, 170000, 190000, 210000, 310000, 350000).

The other baud rates (100000, 200000, 400000, 600000, 700000, 1000000; 115200, 125000, 144000, 150000, 250000, 327680, 330000; 110000, 130000, 140000, 150000, 180000) work well.

For lower baud rate it works even better -- 8k, 9k, 10k, 20k, 30k, 40k, 50k, 60k, 70k, 80k, 90k, 100k all work fine.

For even lower baud rate, it may have some issues. I can not get anything below 7700 to work.

stefanrueger commented 1 year ago

Arduino Nano clone with CH340 and Atmega328P

Could you try on your board

I have been testing autobaud with FTDI FT232L (don't know whether the board has pullups/pulldowns) and with CH330N (the latter does not need external pullups/pulldowns - the chip does everything right). Both USB-TTL chips work well.

tested with some random baud rate not working with the autobaud firmware

Thanks. Yes, your tests gave the expected results b/c the poor little Atmel USARTs can only do certain baud rates: See my comment in the source code

https://github.com/stefanrueger/urboot/blob/77bec7cdfe819697dc85e67d148b931464fafcd1/src/urboot.c#L530-L580

Also see the legend for a autobaud detection that details the set of baud rates the AVRs can do: f_cpu/8n using discrete divisors, n = 1, 2, ..., 256

legend-autobaud

stefanrueger commented 1 year ago

@MCUdude - do you have similar experiences? Which USB-TTL chips have you used?

MCUdude commented 1 year ago

@stefanrueger I've only tried it on this custom DIP-40 board, and it worked all the way from 9600 and up to 2M. This board uses a CH340C USB to serial chip.

Never experienced any issues

stefanrueger commented 1 year ago

OK, let's see what @mcuee's tests bring about. If it's pullups/pulldowns then this could be done by software at a cost of 2 bytes each, though my favourite build, the 510 byte weudhprac dual boot template bootloader, would then be 2 bytes over. I always thought that the serial hardware (ie, the USB-TTL chip) ought to ensure rx is pulled high at receiver side.

MCUdude commented 1 year ago

I've tested the autobaud functionality using a bare-bone ATtiny2313 breakout board without any pull-ups or series resistors on the RX and TX lines. I can confirm that autobaud works perfectly using a CH340G USB to serial adapter, a CP2104 USB to serial adapter from Adafruit and an FT232RL based one from Sparkfun.

stefanrueger commented 1 year ago

Brilliant list of USB-TTL tests. Adding my CH330N, we have already 4 chips under our belt.

mcuee commented 1 year ago

I have no issues with the CH340G on my Arduino Mega Clone (ATmega2560, 5V, 16MHz). The Arduino Nano Clone which has issues (ATmega328P, 5V, 16MHz) is also using the same CH340G chipset. I will try to test the pull-up/pull-down test later as I am not able to test now.

mcuee commented 1 year ago

I can reproduce the issue on another Arduini Nano clone with the same CH340G design but using ATmega168P (5V, 16MHz). So the root cause should be the same. I will try to play with the pull-up/pull-down next week.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c usbasp
 -p m168p -U .\atmega168p_16mhz_115200bps_ee_lednop_fr_ce_ur_vbl.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock
 -P COM10 -b 115200 -p m168p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jpr-c vector 25 
(SPM_Ready) ATmega168P

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c usbasp
 -p m168p -U .\atmega168p_autobaud_ee_lednop_fr_ce_ur_vbl.hex -qq && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock
 -P COM10 -b 115200 -p m168p -xshowall
avrdude_pr1171v6 warning: attempt 1 of 20: not in sync
avrdude_pr1171v6 warning: programmer is not responding; try, eg, -xdelay=200
...
avrdude_pr1171v6 warning: attempt 19 of 20: not in sync
avrdude_pr1171v6 warning: programmer is not responding; try, eg, -xdelay=200
avrdude_pr1171v6 warning: attempt 20 of 20: not in sync
avrdude_pr1171v6 error: unable to open programmer urclock on port COM10

avrdude_pr1171v6 done.  Thank you.
mcuee commented 1 year ago

BTW, the autobaud FW seems to work pretty well for the ATmega2560, tested with some random baud rate. Some do not work (300000, 600000, 800000, 900000; 120000, 160000, 170000, 190000, 210000, 310000, 350000). For even lower baud rate, it may have some issues. I can not get anything below 7700 to work.

Yes, your tests gave the expected results b/c the poor little Atmel USARTs can only do certain baud rates: See my comment in the source code

I tested the Arduino Uno Clone using ATmega328P and ATmega16U2 (USB to Serial FW, using USB CDC-ACM class), it can work with even more baud rates than the CH340G. It works well with the above baud rate (300000, 600000, 800000, 900000; 120000, 160000, 170000, 190000, 210000, 310000, 350000).

As expected, it does not work with anything <=7700 bps (7800bps works).

Official Arduino Uno and Arduino Mega 2560 use ATmega16U2 USB to Serial FW. So urboot autobaud FW should work for many users of such boards.

Official Arduino Nano uses FT232RL

Most of the Uno and Nano clones use CH340 serials.

Note: I am not exactly sure if the ATmega16U2 really talks to the ATmega328P using the baudrate specified though. But at least I can not get other baud rate to work when I use the 115200bps urboot firmware.

Edit: I think it does based on the ATmega16U2 FW source codes from Arduino. https://github.com/arduino/ArduinoCore-avr/blob/master/firmwares/atmegaxxu2/arduino-usbserial/Arduino-usbserial.c#L209

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 300000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 600000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 800000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 900000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 120000 -p m328p -xshowall

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 160000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 170000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 190000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 210000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 310000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 350000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM3
 -b 7800 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega328P
mcuee commented 1 year ago

BTW, for the two Nano clones, picoboot does not work either.

I tested another Uno clone with ATmega328P and CH340G, the test results are the same as the Mega2560 clone with CH340G. This time I pushed it up to 3,000,000 bps (12MHz clock for the CH340G) and the autobaud urboot FW works fine.

So there are some design differences on these Nano clones compared to the Uno clones (both use CH340G) which make autobaud not working.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM5
 -b 3000000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 
(SPM_Ready) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM5
 -b 3000000 -p m328p -U .\hex\Blink.ino.standard.hex

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
avrdude_pr1171v6: device signature = 0x1e950f (probably m328p)
avrdude_pr1171v6: Note: flash memory has been specified, an erase cycle will be performed.
                  To disable this feature, specify the -D option.
avrdude_pr1171v6: erasing chip
avrdude_pr1171v6: reading input file .\hex\Blink.ino.standard.hex for flash
                  with 924 bytes in 1 section within [0, 0x39b]
                  using 8 pages and 100 pad bytes
avrdude_pr1171v6: preparing flash input for device bootloader
avrdude_pr1171v6: writing 924 bytes flash ...

Writing | ################################################## | 100% 1.09 s

avrdude_pr1171v6: 924 bytes of flash written
avrdude_pr1171v6: verifying flash memory against .\hex\Blink.ino.standard.hex

Reading | ################################################## | 100% 1.03 s

avrdude_pr1171v6: 924 bytes of flash verified

avrdude_pr1171v6 done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock
 -P COM5 -b 3000000 -p m328p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 2022-06-10 21.21 .\hex\Blink.ino.standard.hex 924 store 31420 meta 40 boot 384 u7.7 
weu-jprac vector 25 (SPM_Ready) ATmega328P
mcuee commented 1 year ago

I look at the design of the Nano clones and the design may be quite similar to this one. https://oshwlab.com/eeoj/arduino-nano-clone-ch340

The TX/RX LED driving circuitry may be the problem. --> but my clones have 1k Ohm and not 330 ohm for the LED driving. Note: TX LED circuitry is not correct. RP1B (1k ohm) should be moved to the left of the TX LED.

arduino_nano_ch340

Just a comparison, official Arduino Nano has two FT232RL CBUS pins driving the TX/RX LEDs. https://www.arduino.cc/en/uploads/Main/Arduino_Nano-Rev3.2-SCH.pdf

mcuee commented 1 year ago

Official Arduino Uno Rev3 schematics: two GPIO pins of the ATmega16U2 (USB to Serial chip) are driving the TX/RX LEDs. https://www.arduino.cc/en/uploads/Main/Arduino_Uno_Rev3-schematic.pdf

Typical Arduino Uno clone CH340G schematics: the TX/R LEDs driver circuitry is actually similar to my two Nano clones. http://electronoobs.com/eng_arduino_tut31_sch3.php

Note: TX LED driving is not so correct, R8 (1k ohm) should be moved to the right of the TX LED. arduino_uno_scheamtic_ch340

Typical Arduino Uno clone FT232RL schematics: using CBUS pins to drive TX/RX LEDs, similar to official Arduino Nano design. https://oshwlab.com/nata.iiinx88/arduino-uno

MCUdude commented 1 year ago

I've alto tested autobaud on a CH330N with the following schematic. It works perfectly fine. The only difference is that all resistors are 1k, except for R6 which is 10k. It's an older design, so I don't remember why I didn't use 10k for R6. Also, the power flags are either 5V or 3.3V, but for some reason, the text above the power symbols are gone

image
mcuee commented 1 year ago

Interestingly I have another ATmega328P Nano clone (Type C, CH340G, 5V,16MHz) which works well with the autobaud urboot FW (up to 2,490,000bps). I should be able to compare the differences of the different Nano clones next week.

mcuee commented 1 year ago

@MCUdude I think your LED driving circuitry is correct (using 4 x 1k ohm resistor). The clone design may not be correct. Take note the difference in the RX and TX LED design.

It should be using the following sequence. CH330N/340G TXD --> TX LED driving --> 1k ohm --> ATmega328P RXD CH330N/340G RXD <-- 1k ohm <--RX LED driving <-- ATmega328P TXD

But the clone design makes a mistake for either the RX or TX LED driving.

mcuee commented 1 year ago

Further debugging shows an interesting result.

I use another CH340 USB to TTL converter (COM13) to connect to the Nano 168P clone -- without the DTR RC reset add-on -- so I have to use manual reset (by pressing the button after the command). But now it works.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c usbasp -p m168p
 -U .\atmega168p_autobaud_ee_lednop_fr_ce_ur_vbl.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock
 -P COM13  -p m168p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega168P

Then I find out I do not need the external USB to TTL converter either. Rather I can use manually reset and it will work with the on-board CH340G (COM10). This points out some subtle difference between the autobaud FW and the normal FW (no need the manual reset). It could be the reset times out too fast before the baud rate negotiation.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock -P COM10
 -p m168p -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 25 (SPM_Ready) ATmega168P
mcuee commented 1 year ago

It could be the reset times out too fast before the baud rate negotiation

I am thinking that #7 can help in this situation but I am not so sure if it is in scope for urboot or not. I can see that optiboot_x and optiboot_dx has the 8s delay option for chips without proper auto reset.

mcuee commented 1 year ago

I am also testing with a ATmega32A breakout board (5V, 8MHz crystal, CH340G) without the proper DTR RC reset circuitry. It does have a reset button. I can get the 115,200 bps and 1,000,000bps urboot FW working well by pressing the reset button but not the urboot autobaud FW.

Then I tested another ATmega8A breakout board (5V, 16MHz crystal) with an external CH340G USB to TTL converter, I am able to use the reset buttone to get autobaud urboot FW to work.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c usbasp -p m8a
 -U .\atmega8a_autobaud_ee_lednop_fr_ce_ur_vbl.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock
 -P COM13 -p m8a -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 18 
(SPM_RDY) ATmega8A

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock
 -P COM13 -b 500000 -p m8a -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 18 (SPM_RDY) ATmega8A
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v6 -C .\avrdude_pr1171v6.conf -c urclock
 -P COM13 -b 1000000 -p m8a -xshowall

avrdude_pr1171v6: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jprac vector 18 (SPM_RDY) ATmega8A
stefanrueger commented 1 year ago

It could be the reset times out too fast before the baud rate negotiation.

Baud rate detection is fast. The following sequence is needed, tough:

  1. Board resets and gets out of reset; autoboot waits for a sign of life on the rx line
  2. Avrdude sends the first GET_SYNC after the board has come out of reset (see -xdelay=...)
  3. Bootloader is still active and has not timed out (-xdelay value must be less than the WDT timeout)

For manual reset on a board without reset-circuit compile with a WDTO=8S timeout. Upload as follows

  1. Reset the board manually; then
  2. Start avrdude (avrdude plucks the RTS/DTR lines, but since the board does not have a reset circuit no reset happens)

For automated reset it could be that the board takes a loooong time to get out of reset, by which time avrdude had already sent the GET_SYNC; investigate the SUT_CKSEL values in the fuses, or check whether there are particularly large caps in the reset circuit. In this case -xdelay=50 or similar might be your friend.

Are you in a position to compile the bootloaders? Try uncommenting the line

https://github.com/stefanrueger/urboot/blob/016e9575ae44f9685dd2ac1c2504f65aed26d0a9/src/urboot.c#L2232

This creates a software pullup for rx.

Compile by either

make MCU=atmega328p F_CPU=16000000L WDTO=1S AUTOBAUD=1 LED=AtmelPB5 DUAL=0 EEPROM=1 URPROTOCOL=1 FRILLS=7 MOVETO=atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl

or (if you don't get urboot-gcc to work)

./avr-toolchain/5.4.0/bin/avr-gcc -DSTART=0x7e80UL -DRJMPWP=0xcfd6 -Wl,--section-start=.text=0x7e80 -Wl,--section-start=.version=0x7ffa -D_urboot_AVAILABLE=22 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=1S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=1 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf urboot.c
./avr-toolchain/5.4.0/bin/avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.hex
./avr-toolchain/5.4.0/bin/avr-objdump -h -S atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf > atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.lst
mv atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.hex atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex
-- 376 384 u7.7 weu-jPrac atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

Must be on Linux, I am afraid.

mcuee commented 1 year ago

I should be able to build any command line application with proper build instruction under Linux/macOS/Windows. :) I like cross-platform open source projects (eg: libusb, hidapi, libftdi, pyusb, OpenOCD and avrdude). And I have physical machines to run all three OS since 2011. I also run FreeBSD/OpenBSD/NetBSD under VirtualBox but I am less familiar with the BSDs.

I will give it a try to build custom urboot FW.

Going back to the initial issues, I think autobaud FW is really working well. It is the RESET circuitry which can be the problem. The pull-up/pulll-down on the TX/RX lines does not seem to be the issue here.

stefanrueger commented 1 year ago

@mcuee Impressive array of Cross OS experience. Also would be interested which tips you have to better describe how to build the .hex files.

For the time being, here is a hex file with software rx pullup (sbi 0x0b, 0): atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

See if that does the trick.

mcuee commented 1 year ago

For the time being, here is a hex file with software rx pullup (sbi 0x0b, 0): atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex See if that does the trick.

Tested and it does not work as expected -- reset is the problem and not rx/tx pin pull-up/pull-down. I still need to manually press the reset button after the avrdude command.

mcuee commented 1 year ago

First hurdle to build the hex file is with the toolchain.

mcuee@UbuntuSwift3:~/build/avr/urboot/src$ make MCU=atmega328p F_CPU=16000000L WDTO=8S AUTOBAUD=1 LED=AtmelPB5 DUAL=0 EEPROM=1 URPROTOCOL=1 FRILLS=7 MOVETO=atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl
./avr-toolchain/5.4.0/bin/avr-gcc -DSTART=0x7c00UL -DRJMPWP=0xcfff -Wl,--section-start=.text=0x7c00 -Wl,--section-start=.version=0x7ffa -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=8S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=0 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.elf urboot.c
avr-gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.
./avr-toolchain/5.4.0/bin/avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.elf atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.hex
./avr-toolchain/5.4.0/bin/avr-objcopy: 'atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.elf': No such file
make: *** [Makefile:719: atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.hex] Error 1

mcuee@UbuntuSwift3:~/build/avr/urboot/src$ ./avr-toolchain/5.4.0/bin/avr-gcc -DSTART=0x7e80UL -DRJMPWP=0xcfd6 -Wl,--section-start=.text=0x7e80 -Wl,--section-start=.version=0x7ffa -D_urboot_AVAILABLE=22 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=1S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=1 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf urboot.c
urboot.c:1356:19: warning: call-clobbered register used for global register variable
 register uint16_t zaddress asm("r30");
                   ^
urboot.c:1356:19: warning: call-clobbered register used for global register variable
avr-gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.
mcuee commented 1 year ago

But no problem for me -- I can use the gcc-avr and avr-libc provded by Ubuntu 20.04 to build the hex file.

mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avr-gcc -DSTART=0x7e80UL -DRJMPWP=0xcfd6 -Wl,--section-start=.text=0x7e80 -Wl,--section-start=.version=0x7ffa -D_urboot_AVAILABLE=22 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=8S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=1 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf urboot.c
urboot.c:1356:19: warning: call-clobbered register used for global register variable
 register uint16_t zaddress asm("r30");
                   ^
urboot.c:1356:19: warning: call-clobbered register used for global register variable
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.hex
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avr-objdump -h -S atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf > atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.lst
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ mv atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.hex atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex
mcuee commented 1 year ago

The result hex file works perfectly. I do not need to manually press the button any more.

Strange thing is that it seems to work with any baudrate >=400bps, even rediculously high numbers above the crystal frequency (16MHz). Maybe it is not really true. Probaly Linux just caps the max baud rate it uses.

mcuee@UbuntuSwift3:~/build/avr/urboot/src$ ls *.hex
atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c usbasp -p m328p
 -U ./atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex -qq && echo OK
OK

mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 115200 -p m328p -xshowall

avrdude: AVR device initialized and ready to accept instructions
ffffffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jPrac vector 25 
(SPM_Ready) ATmega328P
mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 115200 -p m328p
 -U ./blink_m328p.hex 

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file ./blink_m328p.hex for flash
         with 1030 bytes in 1 section within [0, 0x405]
         using 9 pages and 122 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 1030 bytes flash ...

Writing | ################################################## | 100% 0.21 s 

avrdude: 1030 bytes of flash written
avrdude: verifying flash memory against ./blink_m328p.hex

Reading | ################################################## | 100% 0.13 s 

avrdude: 1030 bytes of flash verified

avrdude done.  Thank you.

mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 115200 -p m328p -xshowall

avrdude: AVR device initialized and ready to accept instructions
ffffffffffff 2022-11-20 12.58 blink_m328p.hex 1030 store 31327 meta 27 boot 384 u7.7 weu-jPrac vector 25 
(SPM_Ready) ATmega328P

mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 500000 -p m328p -xshowall

avrdude: AVR device initialized and ready to accept instructions
ffffffffffff 2022-11-20 12.58 blink_m328p.hex 1030 store 31327 meta 27 boot 384 u7.7 weu-jPrac vector 25 
(SPM_Ready) ATmega328P

mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 16000000 -p m328p -xshowall

avrdude: AVR device initialized and ready to accept instructions
ffffffffffff 2022-11-20 12.58 blink_m328p.hex 1030 store 31327 meta 27 boot 384 u7.7 weu-jPrac vector 25 
(SPM_Ready) ATmega328P

mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 20000000 -p m328p -xshowall

avrdude: AVR device initialized and ready to accept instructions
ffffffffffff 2022-11-20 12.58 blink_m328p.hex 1030 store 31327 meta 27 boot 384 u7.7 weu-jPrac vector 25 
(SPM_Ready) ATmega328P

mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 400 -p m328p -xshowall

avrdude: AVR device initialized and ready to accept instructions
ffffffffffff 2022-11-20 12.58 blink_m328p.hex 1030 store 31327 meta 27 boot 384 u7.7 weu-jPrac vector 25 
(SPM_Ready) ATmega328P

mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 200000000 -p m328p -xshowall

avrdude: AVR device initialized and ready to accept instructions
ffffffffffff 2022-11-20 12.58 blink_m328p.hex 1030 store 31327 meta 27 boot 384 u7.7 weu-jPrac vector 25
 (SPM_Ready) ATmega328P
mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 2000000000 -p m328p -xshowall

avrdude: AVR device initialized and ready to accept instructions
ffffffffffff 2022-11-20 12.58 blink_m328p.hex 1030 store 31327 meta 27 boot 384 u7.7 weu-jPrac vector 25 
(SPM_Ready) ATmega328P
mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 20000000000 -p m328p -xshowall

avrdude: AVR device initialized and ready to accept instructions
ffffffffffff 2022-11-20 12.58 blink_m328p.hex 1030 store 31327 meta 27 boot 384 u7.7 weu-jPrac vector 25 
(SPM_Ready) ATmega328P
mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ avrdude -c urclock -P /dev/ttyUSB0 -b 200000000000 -p m328p -xshowall

avrdude: AVR device initialized and ready to accept instructions
ffffffffffff 2022-11-20 12.58 blink_m328p.hex 1030 store 31327 meta 27 boot 384 u7.7 weu-jPrac vector 25 
(SPM_Ready) ATmega328P
mcuee commented 1 year ago

It also works fine with Windows -- down to 7800 bps and up to 3,000,000bps.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v7 -C .\avrdude_pr1171v7.conf -c urclock
 -P COM10 -b 3000000 -p m328p -xshowall

avrdude_pr1171v7: AVR device initialized and ready to accept instructions
0000ffffffff 2022-11-20 12.58 blink_m328p.hex 1030 store 31327 meta 27 boot 384 u7.7 weu-jPrac vector 25 
(SPM_Ready) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v7 -C .\avrdude_pr1171v7.conf -c urclock
 -P COM10 -b 7800 -p m328p -U .\zeros31KB.hex -F

avrdude_pr1171v7: AVR device initialized and ready to accept instructions
avrdude_pr1171v7: device signature = 0x1e950f (probably m328p)
avrdude_pr1171v7: Note: flash memory has been specified, an erase cycle will be performed.
                  To disable this feature, specify the -D option.
avrdude_pr1171v7: erasing chip
avrdude_pr1171v7: reading input file .\zeros31KB.hex for flash
                  with 31744 bytes in 1 section within [0, 0x7bff]
                  using 248 pages and 0 pad bytes
avrdude_pr1171v7 warning: not patching jmp to application as input does not start with a vector table
avrdude_pr1171v7: preparing flash input for device bootloader
avrdude_pr1171v7: writing 31744 bytes flash ...

Writing | ################################################## | 100% 46.32 s

avrdude_pr1171v7: 31744 bytes of flash written
avrdude_pr1171v7: verifying flash memory against .\zeros31KB.hex

Reading | ################################################## | 100% 44.34 s

avrdude_pr1171v7: 31744 bytes of flash verified

avrdude_pr1171v7 done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v7 -C .\avrdude_pr1171v7.conf -c urclock
 -P COM10 -b 3000000 -p
 m328p -U .\zeros31KB.hex -F

avrdude_pr1171v7: AVR device initialized and ready to accept instructions
avrdude_pr1171v7: device signature = 0x1e950f (probably m328p)
avrdude_pr1171v7: Note: flash memory has been specified, an erase cycle will be performed.
                  To disable this feature, specify the -D option.
avrdude_pr1171v7: erasing chip
avrdude_pr1171v7: reading input file .\zeros31KB.hex for flash
                  with 31744 bytes in 1 section within [0, 0x7bff]
                  using 248 pages and 0 pad bytes
avrdude_pr1171v7 warning: not patching jmp to application as input does not start with a vector table
avrdude_pr1171v7: preparing flash input for device bootloader
avrdude_pr1171v7: writing 31744 bytes flash ...

Writing | ################################################## | 100% 32.20 s

avrdude_pr1171v7: 31744 bytes of flash written
avrdude_pr1171v7: verifying flash memory against .\zeros31KB.hex

Reading | ################################################## | 100% 30.42 s

avrdude_pr1171v7: 31744 bytes of flash verified

avrdude_pr1171v7 done.  Thank you.
mcuee commented 1 year ago

I think I can close this issue now that it is sorted out.

MCUdude commented 1 year ago

So, building your own bootloader solved the issue?

mcuee commented 1 year ago

So, building your own bootloader solved the issue?

Yes, that is correct.

mcuee commented 1 year ago

BTW, I can build the hex file under Windows under MSYS2. The hex file works fine.

As of now MSYS2 perl lacks some modules so I can not use urboot-gcc yet. But I can use the alternative method mentioned by @stefanrueger.

I believe macOS will work as well (I will test later).

$ avr-gcc -DSTART=0x7e80UL -DRJMPWP=0xcfd6 -Wl,--section-start=.text=0x7e80 -Wl,--section-start=.version=0x7ffa -D_urboot_AVAILABLE=22 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=8S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=1 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf urboot.c
urboot.c:1356:19: warning: call-clobbered register used for global register variable
 register uint16_t zaddress asm("r30");
                   ^~~~~~~~
urboot.c:1356:19: warning: call-clobbered register used for global register variable

$ avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.hex

$ avr-objdump -h -S atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf > atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.lst

xiaof@LAPTOP-913SIMUD MINGW64 /c/work/avr/urboot/src
$ mv atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.hex atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

$ avr-gcc -v
Using built-in specs.
Reading specs from c:/msys64/mingw64/bin/../lib/gcc/avr/8.5.0/device-specs/specs-avr2
COLLECT_GCC=C:\msys64\mingw64\bin\avr-gcc.exe
COLLECT_LTO_WRAPPER=c:/msys64/mingw64/bin/../libexec/gcc/avr/8.5.0/lto-wrapper.exe
Target: avr
Configured with: ../gcc-8.5.0/configure --build=x86_64-w64-mingw32 --prefix=/mingw64 --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --disable-shared --disable-threads --disable-libgomp --disable-libada --with-dwarf2 --enable-mingw-wildcard
Thread model: single
gcc version 8.5.0 (GCC)

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v7 -C .\avrdude_pr1171v7.conf -c usbasp
 -p m328p -U .\atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex -qq && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v7 -C .\avrdude_pr1171v7.conf -c urclock
 -P COM10 -b 1000000 -p m328p -xshowall

avrdude_pr1171v7: AVR device initialized and ready to accept instructions
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 384 u7.7 weu-jPrac vector 25 (SPM_Ready) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v7 -C .\avrdude_pr1171v7.conf -c urclock
 -P COM10 -U .\hex\Blink.ino.standard.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1171v7 -C .\avrdude_pr1171v7.conf -c urclock
 -P COM10 -b 3000000 -p m328p -xshowall

avrdude_pr1171v7: AVR device initialized and ready to accept instructions
0000ffffffff 2022-06-10 21.21 Blink.ino.standard.hex 924 store 31426 meta 34 boot 384 u7.7 
weu-jPrac vector 25 (SPM_Ready) ATmega328P
mcuee commented 1 year ago

No issues under macOS with Homebrew as well. I have not figured how to use urboot-gcc yet.

mcuee@mcuees-Mac-mini src % avr-gcc -DSTART=0x7e80UL -DRJMPWP=0xcfd6 -Wl,--section-start=.text=0x7e80 -Wl,--section-start=.version=0x7ffa -D_urboot_AVAILABLE=22 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=8S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=1 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf urboot.c
urboot.c:1356:19: warning: call-clobbered register used for global register variable
 1356 | register uint16_t zaddress asm("r30");
      |                   ^~~~~~~~
urboot.c:1356:19: warning: call-clobbered register used for global register variable
mcuee@mcuees-Mac-mini src % avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.hex

mcuee@mcuees-Mac-mini src % avr-objdump -h -S atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.elf > atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.lst

mcuee@mcuees-Mac-mini src % mv atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto1s_ur.hex atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

mcuee@mcuees-Mac-mini src % ls -la *.hex
-rw-r--r--  1 mcuee  staff  1070 Nov 20 16:49 atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

mcuee@mcuees-Mac-mini src % cat atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex 
:107E8000112424B614BE80E081D021FEEBC089E22B
:107E90007DD0E0ECF0E0AFE7BFEF4899FECF9096E1
:107EA000489BFDCFB4831197F1F7B2E0B083B8E1FE
:107EB000B183B6E0B28358D0C82F823571F46DD04B
:107EC000F0E0E0E0CDEF83E086D0A895E058FF4FEA
:107ED000C150C9F787E741D0EECF8D7FF1F451D083
:107EE000D82FA0E0B1E040D08D93DA13FCCF55D06D
:107EF000C1110FC0A0E0B1E0F999FECF1FBAF2BDE9
:107F0000E1BD8D9180BDFA9AF99A3196DA13F4CFDA
:107F1000E1CFA0E0B1E04BD0DDCFC33041F431D0B0
:107F2000C82F3BD0859119D0C150E1F7D3CFC130D4
:107F300071F427D0C82F31D0F999FECFF2BDE1BD41
:107F4000F89A80B50AD03196C150B1F7C3CFC13588
:107F500011F488E01BD021D0BDCF9091C00095FFD7
:107F6000FCCF8093C60008952D9A259A8091C00079
:107F700087FFFCCF84FD14C0A8958091C6002D9882
:107F80000895F2DFE82FF0DFF82FEECF98E1A89503
:107F900090936000809360000895E6DF803219F0CE
:107FA00088E0F4DFFFCF80EAD8CFFB01DC0160E896
:107FB0006A0F9F01E0388EE7F80790F483E00BD05A
:107FC00081E00D901D9007D03296A613FACFF901EB
:107FD00085E001D081E187BFE89507B600FCFDCFC1
:047FE00011240895CB
:067FFA000319D6CFE73F9A
:0400000300007E80FB
:00000001FF

mcuee@mcuees-Mac-mini src % avr-gcc -v
Using built-in specs.
Reading specs from /opt/homebrew/Cellar/avr-gcc@9/9.4.0/lib/avr-gcc/9/gcc/avr/9.4.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/avr-gcc@9/9.4.0/libexec/gcc/avr/9.4.0/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/opt/homebrew/Cellar/avr-gcc@9/9.4.0 --libdir=/opt/homebrew/Cellar/avr-gcc@9/9.4.0/lib/avr-gcc/9 --enable-languages=c,c++ --with-ld=/opt/homebrew/opt/avr-binutils/bin/avr-ld --with-as=/opt/homebrew/opt/avr-binutils/bin/avr-as --disable-nls --disable-libssp --disable-shared --disable-threads --disable-libgomp --with-dwarf2 --with-avrlibc --with-system-zlib --with-pkgversion='Homebrew AVR GCC 9.4.0' --with-bugurl=https://github.com/osx-cross/homebrew-avr/issues SED=/usr/bin/sed
Thread model: single
gcc version 9.4.0 (Homebrew AVR GCC 9.4.0)
mcuee commented 1 year ago

Okay, I figured how to use urboot-gcc by installing the CPAN package FILE:HomeDir. But the Makefile may need further work.

mcuee@mcuees-Mac-mini src % ./urboot-gcc -toolchain=system -DSTART=0x7e80UL -DRJMPWP=0xcfd6 -Wl,--section-start=.text=0x7e80 -Wl,--section-start=.version=0x7ffa -D_urboot_AVAILABLE=22 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=8S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=1 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.elf urboot.c
avr-gcc -DSTART=0x7e80UL -DRJMPWP=0xcfd6 -Wl,--section-start=.text=0x7e80 -Wl,--section-start=.version=0x7ffa -DSTART=0x7e80UL -DRJMPWP=0xcfd6 -Wl,--section-start=.text=0x7e80 -Wl,--section-start=.version=0x7ffa -D_urboot_AVAILABLE=22 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=8S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=1 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.elf urboot.c
      |                   ^~~~~~~~
mcuee@mcuees-Mac-mini src % avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.elf atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.hex

mcuee@mcuees-Mac-mini src % avr-objdump -h -S atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.elf > atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.lst

mcuee@mcuees-Mac-mini src % mv atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.hex atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex                            

mcuee@mcuees-Mac-mini src % ls *.hex
atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

The hex works fine but I find an issue with detection of readline under macOS.

stefanrueger commented 1 year ago

So, building your own bootloader solved the issue?

Yes, that is correct.

Hang on a second. The pre-compiled bootloaders are also just only self-built bootloaders . So, what is the difference? Can you share your the make command, the output of hexls *.hex on your system, the resulting .hex and .lst files, please?

liblto_plugin.so not found

Thanks for finding this problem. I have now pushed the missing avr-toolchain library files to the urboot repository (they fell victim to .gitignore).

./urboot-gcc -toolchain=system -DSTART=0x7e80UL -DRJMPWP=0xcfd6

This does not sound right: urboot-gcc is a wrapper that computes the START and RJMPWP defines and injects them into the command line for avr-gcc, so (from memory) seems wrong to pass these parameters to urboot-gcc.

But congrats on being able to compile your own bootloaders. I find using the older avr-gcc versions 5.4.0 and 4.8.1 to be particularly space efficient, hence the old toolchains in the project.

stefanrueger commented 1 year ago

@mcuee So, just to be clear: software pullup of rx in the bootloader is not needed, right?

mcuee commented 1 year ago

So, building your own bootloader solved the issue? Yes, that is correct.

Hang on a second. The pre-compiled bootloaders are also just only self-built bootloaders . So, what is the difference? Can you share your the make command, the output of hexls *.hex on your system, the resulting .hex and .lst files, please?

Only difference is -DWDTO=8S.

mcuee@mcuees-Mac-mini src % avr-gcc -DSTART=0x7e80UL -DRJMPWP=0xcfd6 -Wl,--section-start=.text=0x7e80 -Wl,--section-start=.version=0x7ffa -D_urboot_AVAILABLE=22 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=8S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=1 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.elf urboot.c
urboot.c:1356:19: warning: call-clobbered register used for global register variable
 1356 | register uint16_t zaddress asm("r30");
      |                   ^~~~~~~~
urboot.c:1356:19: warning: call-clobbered register used for global register variable

mcuee@mcuees-Mac-mini src % avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.elf atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.hex

mcuee@mcuees-Mac-mini src % avr-objdump -h -S atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.elf > atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.lst

mcuee@mcuees-Mac-mini src % mv atmega328p_16mhz_auto_115200bps_ev1f7_ledPB5_wdto8s_ur.hex atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

mcuee@mcuees-Mac-mini src % ./hexls *.hex
362 384 u7.7 weu-jprac atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

atmega328p_autoboot_macos_build.zip

mcuee commented 1 year ago

@mcuee So, just to be clear: software pullup of rx in the bootloader is not needed, right?

Yes, this is correct.

mcuee commented 1 year ago

./urboot-gcc -toolchain=system -DSTART=0x7e80UL -DRJMPWP=0xcfd6 This does not sound right: urboot-gcc is a wrapper that computes the START and RJMPWP defines and injects them into the command line for avr-gcc, so (from memory) seems wrong to pass these parameters to urboot-gcc.

No wonder the warnings. I think there are other things not correct. I need to figure out how to use urboot-gcc and the Makefile properly under Linux and macOS.

stefanrueger commented 1 year ago

Thanks for sharing the successful bootloader. Re warnings:

urboot.c:1356:19: warning: call-clobbered register used for global register variable
 1356 | register uint16_t zaddress asm("r30");
      |                   ^~~~~~~~
urboot.c:1356:19: warning: call-clobbered register used for global register variable

this is actually OK. Look at my comment here

https://github.com/stefanrueger/urboot/blob/1d5405e007c57c4d9b01c79113551447f7f503f7/src/urboot.c#L1341-L1353

What problems do you see with the Makefile?

mcuee commented 1 year ago

What problems do you see with the Makefile?

I meant to say I have not figured how to use urboot-gcc yet under macOS and therefore I am not able to figure out how to use the Makefile. Currently the Makefile is using the Linux gcc toolchain. I need to find a way to specify the system provided toolchain.

mcuee commented 1 year ago

liblto_plugin.so not found

Thanks for finding this problem. I have now pushed the missing avr-toolchain library files to the urboot repository (they fell victim to .gitignore).

The issue is not fixed yet, tested under Linux.

mcuee@UbuntuSwift3:~/build/avr/urboot/src$ make MCU=atmega328p F_CPU=16000000L WDTO=8S AUTOBAUD=1 LED=AtmelPB5 DUAL=0 EEPROM=1 URPROTOCOL=1 FRILLS=7 MOVETO=atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl
./avr-toolchain/5.4.0/bin/avr-gcc -DSTART=0x7c00UL -DRJMPWP=0xcfff -Wl,--section-start=.text=0x7c00 -Wl,--section-start=.version=0x7ffa -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=8S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=0 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.elf urboot.c
avr-gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.
./avr-toolchain/5.4.0/bin/avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.elf atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.hex
./avr-toolchain/5.4.0/bin/avr-objcopy: 'atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.elf': No such file
make: *** [Makefile:719: atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.hex] Error 1
mcuee commented 1 year ago

The fix is easy though -- need to add the soft link. You may want to add them as well for the toolchains.

mcuee@UbuntuSwift3:~/build/avr/urboot/src/avr-toolchain/5.4.0/libexec/gcc/avr/5.4.0$ ln -sf liblto_plugin.so.0.0.0  liblto_plugin.so

mcuee@UbuntuSwift3:~/build/avr/urboot/src$ make MCU=atmega328p F_CPU=16000000L WDTO=8S AUTOBAUD=1 LED=AtmelPB5 DUAL=0 EEPROM=1 URPROTOCOL=1 FRILLS=7 MOVETO=atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl
./avr-toolchain/5.4.0/bin/avr-gcc -DSTART=0x7e00UL -DRJMPWP=0xcf96 -Wl,--section-start=.text=0x7e00 -Wl,--section-start=.version=0x7ffa -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=8S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=0 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.elf urboot.c
./avr-toolchain/5.4.0/bin/avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.elf atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.hex
./avr-toolchain/5.4.0/bin/avr-objdump -h -S atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.elf > atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.lst
mv atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto8s_ur.hex atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex
-- 358 512 u7.7 weu-hprac atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

mcuee@UbuntuSwift3:~/build/avr/urboot/src$ make MCU=atmega328p F_CPU=16000000L WDTO=1S AUTOBAUD=1 LED=AtmelPB5 DUAL=0 EEPROM=1 URPROTOCOL=1 FRILLS=7 MOVETO=atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl_1s
./avr-toolchain/5.4.0/bin/avr-gcc -DSTART=0x7e00UL -DRJMPWP=0xcf96 -Wl,--section-start=.text=0x7e00 -Wl,--section-start=.version=0x7ffa -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=1S -DAUTOBAUD=1 -DLED=AtmelPB5 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=0 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto1s_ur.elf urboot.c
./avr-toolchain/5.4.0/bin/avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto1s_ur.elf atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto1s_ur.hex
./avr-toolchain/5.4.0/bin/avr-objdump -h -S atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto1s_ur.elf > atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto1s_ur.lst
mv atmega328p_16mhz_auto_115200bps_ef7_ledPB5_wdto1s_ur.hex atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl_1s.hex
-- 358 512 u7.7 weu-hprac atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl_1s.hex
mcuee commented 1 year ago 
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ ./hexls *.hex
358 512 u7.7 weu-hprac atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl_1s.hex
358 512 u7.7 weu-hprac atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

mcuee@UbuntuSwift3:~/build/avr/urboot/src$ ./hexls ../bootloaders/atmega328p/autobaud/atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex 
362 384 u7.7 weu-jprac ../bootloaders/atmega328p/autobaud/atmega328p_autobaud_ee_led+b5_fr_ce_ur_vbl.hex

@stefanrueger Now that I am using the same toolchain under Linux, just wondering what is the difference here in terms of code size and used flash space.

How should I invoke the Makefile if I want to use the system provded toolchain (urboot-gcc -toolchain=system`)?

stefanrueger commented 1 year ago

How should I invoke the Makefile if I want to use the system provded toolchain (urboot-gcc -toolchain=system`)?

The Makefile selects a suitable toolchain for the bootloader, but if you want to force a particular version it is TOOLVER=system or, eg, TOOLVER=5.4.0 as argument to make

Here a few truly random examples how to invoke make

make MCU=atmega1284p F_CPU=20000000L BAUD_RATE=500000 VBL=0 EEPROM=1 TEMPLATE=1 URPROTOCOL=1 FRILLS=1 MOVETO=atmega1284p_20mhz_500000bps_ee_lednop_ur
make MCU=atmega325pa F_CPU=22118400L BAUD_RATE=38400 VBL=0 EEPROM=0 TEMPLATE=1 URPROTOCOL=1 FRILLS=1 MOVETO=atmega325pa_22mhz1184_38400bps_lednop_ur
make MCU=at90pwm2 F_CPU=14745600L BAUD_RATE=460800 VBL=0 EEPROM=1 TEMPLATE=1 URPROTOCOL=1 FRILLS=0 MOVETO=at90pwm2_14mhz7456_460800bps_ee_ur
make MCU=atmega328p F_CPU=11059200L BAUD_RATE=57600 VBL=0 EEPROM=0 LEDPOLARITY=-1 LED=AtmelPB1 URPROTOCOL=0 FRILLS=7 MOVETO=atmega328p_11mhz0592_57600bps_led-b1_fr_ce
make MCU=atmega8515 F_CPU=12000000L BAUD_RATE=9600 VBL=1 EEPROM=1 TEMPLATE=1 URPROTOCOL=1 FRILLS=7 MOVETO=atmega8515_12mhz_9600bps_ee_lednop_fr_ce_ur_vbl
make MCU=atmega649a F_CPU=14745600L BAUD_RATE=19200 VBL=0 EEPROM=1 TEMPLATE=1 URPROTOCOL=0 FRILLS=0 MOVETO=atmega649a_14mhz7456_19200bps_ee
make MCU=atmega64rfr2 F_CPU=4000000L BAUD_RATE=19200 VBL=0 EEPROM=1 TEMPLATE=1 URPROTOCOL=1 FRILLS=0 MOVETO=atmega64rfr2_4mhz_19200bps_ee_ur
make MCU=atmega128rfa1 F_CPU=7372800L BAUD_RATE=230400 VBL=1 EEPROM=1 TEMPLATE=1 URPROTOCOL=1 FRILLS=6 MOVETO=atmega128rfa1_7mhz3728_230400bps_ee_lednop_fr_ur_vbl
make MCU=ata6286 F_CPU=11059200L BAUD_RATE=9600 SWIO=1 RX=AtmelPB0 TX=AtmelPB1 VBL=0 EEPROM=0 TEMPLATE=1 URPROTOCOL=0 FRILLS=6 MOVETO=ata6286_11mhz0592_9600bps_rxb0_txb1_lednop_fr
make MCU=ata5831 F_CPU=2000000L BAUD_RATE=19200 SWIO=1 RX=AtmelPB0 TX=AtmelPB1 VBL=0 EEPROM=1 TEMPLATE=1 URPROTOCOL=1 FRILLS=0 MOVETO=ata5831_2mhz_19200bps_rxb0_txb1_ee_ur

Here all make-commands.zip that I used for the pre-compiled bootloaders. Note they are generated by mkallbootloaders. Afterwards the script deletes redundant bootloaders (eg, when a bootloader with more features occupies the same size as another one with less the later one is deleted).

stefanrueger commented 1 year ago

The fix is easy though -- need to add the soft link.

Thanks, I just pushed symbolic links, too.

stefanrueger commented 1 year ago

Only difference is -DWDTO=8S.

So timing? Well, I don't get this. The bootloaders were compiled with -DWDTO=1S. Plenty'o time for the host to send the first command (and can delay, too, with -xdelay=...). Baud rate "negotiation" takes as long as it takes to send one byte (< 1ms).

Are you sure you set the fuses correct? And deleted flash before burning the bootloader? Note, you cannot put a program and a vector bootloader onto the chip at the same time. The vector bootloader must be burned onto an erased chip first. Then you can upload with the vector bootloader (remember -c urclock patches the application - you miss this when you burn the unpatched application plus vector bootloader at the same time).

stefanrueger commented 1 year ago

It works well with the above baud rate (300000, 600000, 800000, 900000; 120000, 160000, 170000, 190000, 210000, 310000, 350000).

Cannot imagine. A 16 MHz AVR can only tolerate baud rates in the following intervals (UART2X=1) with the USART_BRL register and a 1.5% tolerance:

  [1970000, 2030000] = [0.985*F_CPU/(8*1), 1.015*F_CPU/(8*1)], F_CPU = 16 MHz
  [ 985000, 1015000] = [0.985*F_CPU/(8*2), 1.015*F_CPU/(8*2)]
  [ 656667,  676667]
  [ 492500,  507500]
  [ 394000,  406000]
  [ 328333,  338333]
  [ 281429,  290000]
  [ 246250,  253750]
  [ 218889,  225556]
  [ 197000,  203000]
  [ 179091,  184545]
  [ 164167,  169167]
  [ 151538,  156154]
  [ 140714,  145000]
  [ 131333,  135333]
  [ 123125,  126875]
  [ 115882,  119412] <-- 115200 baud is out of specs for a 16 MHz MCU
  [ 109444,  112778]
  [ 103684,  106842]
  [  98500,  101500]
  [  93810,   96667]
  [  89545,   92273]
  [  85652,   88261]
  [  82083,   84583]
  [  78800,   81200]
  [  75769,   78077]
  [  72963,   75185]
  [  70357,   72500]
  [  67931,   70000]
  [  65667,   67667]
  [  63548,   65484]
  [  61563,   63437]
  [  7695,    61515] = [0.985*F_CPU/(8*256), 1.015*F_CPU/(8*33)]

I think what is happening is that when Linux cannot generate the requested baud rate it uses a nearby standard one. The baud rates that the USB-TTL parts can generate Linux-side are much more fine grained than AVR USART baud rates, but still there is a limit in the driver software.

stefanrueger commented 1 year ago

@MCUdude and @mcuee: I have now implemented a further safety feature for urboot bootloaders: PROTECTRESET This ensures that the bootloder writes an rjmp from the reset vector to the bootloader whenever it writes Page 0. This - together with all the checks in -c urclock makes it all but impossible for a vector bootloader to be corrupted/disabled.

Whenever a vector bootloader is being compiled and there are enough bytes left, this protection is automatically built in. It is visible as a capital P in the features. So j/P is the same good protection as p/h. You need to update avrdude to the newest version in PR https://github.com/avrdudes/avrdude/pull/1171

I think this is now the last addition I do for urboot after sorting out autobaud and security. Unless there are bugs you see in the next two weeks, I'll release v7.7 of urboot, the first public release!

mcuee commented 1 year ago

I think what is happening is that when Linux cannot generate the requested baud rate it uses a nearby standard one.

That is what I believe as well.