Closed mariusgreuel closed 1 year ago
mcuee
commented
1 year ago Ah, I do not have good testing facility to carry out test for urboot for ATtiny chips. My tests were more on ATmega328P and ATmega2560.
@MCUdude has done quite some tests of urboot on ATtiny chips but he is carrying out tests on macOS.
@stefanrueger Maybe you want to take a look as well.
mcuee
commented
1 year ago I will try ATTiny88 (MH Tiny) first.
Step 1 is to get optiboot working first.
1) ATTinyCore Optiboot seems to work (PD6 as TXD and PD7 as RXD). https://github.com/SpenceKonde/ATTinyCore/blob/v2.0.0-devThis-is-the-head-submit-PRs-against-this/avr/extras/MHET_Tiny.png
mcuee
commented
1 year ago Step 2 is to get Urboot working on the board. I have tried the pre-compiled bootloader and they do not seem to work for my board (I suspect the reason is the short WDT timeout of 1s).
In the end I build one hex file which seems to work fine under Linux.
Note: LED is PD0 and not PB0.
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ make MCU=attiny88 F_CPU=8000000L WDTO=8S AUTOBAUD=0 LED=AtmelPB0 LEDPOLARITY=1 DUAL=0 EEPROM=1 URPROTOCOL=1 FRILLS=7 SWIO=1 TX=AtmelPD6 RX=AtmelPD7 BAUD_RATE=19200
./avr-toolchain/5.4.0/bin/avr-gcc -DSTART=0x1e80UL -DRJMPWP=0xcfd8 -Wl,--section-start=.text=0x1e80 -Wl,--section-start=.version=0x1ffa -D_urboot_AVAILABLE=22 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=attiny88 -DF_CPU=8000000L -Wno-clobbered -DWDTO=8S -DAUTOBAUD=0 -DBAUD_RATE=19200 -DLED=AtmelPB0 -DLEDPOLARITY=1 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=0 -DSWIO=1 -DTX=AtmelPD6 -DRX=AtmelPD7 -Wl,--relax -nostartfiles -nostdlib -o attiny88_8mhz_19200bps_ef7_swio1_txPD6_rxPD7_ledPB0_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 attiny88_8mhz_19200bps_ef7_swio1_txPD6_rxPD7_ledPB0_wdto8s_ur.elf attiny88_8mhz_19200bps_ef7_swio1_txPD6_rxPD7_ledPB0_wdto8s_ur.hex
./avr-toolchain/5.4.0/bin/avr-objdump -h -S attiny88_8mhz_19200bps_ef7_swio1_txPD6_rxPD7_ledPB0_wdto8s_ur.elf > attiny88_8mhz_19200bps_ef7_swio1_txPD6_rxPD7_ledPB0_wdto8s_ur.lst
-- 362 384 u7.7 weu-hpr-c attiny88_8mhz_19200bps_ef7_swio1_txPD6_rxPD7_ledPB0_wdto8s_ur.hex
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c usbasp -p t88 -U ./attiny88_8mhz_19200bps_ef7_swio1_txPD6_rxPD7_ledPB0_wdto8s_ur.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9311 (probably t88)
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 ./attiny88_8mhz_19200bps_ef7_swio1_txPD6_rxPD7_ledPB0_wdto8s_ur.hex for flash
with 362 bytes in 2 sections within [0x1e80, 0x1fff]
using 6 pages and 22 pad bytes
avrdude: writing 362 bytes flash ...
Writing | ################################################## | 100% 0.01 s
avrdude: 362 bytes of flash written
avrdude: verifying flash memory against ./attiny88_8mhz_19200bps_ef7_swio1_txPD6_rxPD7_ledPB0_wdto8s_ur.hex
Reading | ################################################## | 100% 0.00 s
avrdude: 362 bytes of flash verified
avrdude done. Thank you.
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c usbasp -p t88 -qqt
avrdude> dump lfuse
0000 e2 |. |
avrdude> dump hfuse
0000 df |. |
avrdude> dump efuse
0000 fe |. |
avrdude> quit
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c urclock -P /dev/ttyUSB0 -b 19200 -p t88 -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-hpr-c vector 0 (RESET) ATtiny88
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c urclock -P /dev/ttyUSB0 -b 19200 -p t88 -U Blink_t88.ino.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9311 (probably t88)
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_t88.ino.hex for flash
with 468 bytes in 1 section within [0, 0x1d3]
using 8 pages and 44 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 468 bytes flash ...
Writing | ################################################## | 100% 0.38 s
avrdude: 468 bytes of flash written
avrdude: verifying flash memory against Blink_t88.ino.hex
Reading | ################################################## | 100% 0.31 s
avrdude: 468 bytes of flash verified
avrdude done. Thank you.
And then it seems to work under Windows as well. So I can not reproduce the isse on my side. I am using a CH340 USB-TTL converter.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM6 -b 19200 -p t88 -xshowall
avrdude: 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-hpr-c vector 0 (RESET) ATtiny88
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM6 -b 19200 -p t88 -U Blink_tiny88.ino.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9311 (probably t88)
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_tiny88.ino.hex for flash
with 468 bytes in 1 section within [0, 0x1d3]
using 8 pages and 44 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 468 bytes flash ...
Writing | ################################################## | 100% 0.43 s
avrdude: 468 bytes of flash written
avrdude: verifying flash memory against Blink_tiny88.ino.hex
Reading | ################################################## | 100% 0.36 s
avrdude: 468 bytes of flash verified
avrdude done. Thank you.
stefanrueger
commented
1 year ago @mariusgreuel Have you tried to set and vary -xdelay=100? If the board takes an uncharacteristically long time to get out of reset that can be helpful. Does your USB/serial chip reset the board when RTS/DTS is plucked?
Does the same board board work under Linux/MacOS?
Yes, it's a pity that the windows timeout behaves in a different way to the Linux/Posix timeout. AVRDUDE use the same number of milliseconds for Windows timeout and Posix timeout but there is a different behaviour when reading bytes. I once tried to understand serial_w32SetTimeOut() but the documentation that I looked at was not entirely clear to me. There is a complexity with timeouts of between-character timeouts etc that is unwanted/not needed here and makes read() behave differently in both worlds.
Unfortunately, I cannot test what that Windows timeout does to read(). Ideally, Windows read and Posix read would behave in the same way. The urclock/urboot synchronisation for the host/AVR communication was developed with Posix behaviour of read() and Posix timeout.
timeout of 10ms, so quite often, ser_recv only returns one byte instead of two
When the AVR sends two bytes as a reply to the GET_SYNC command they will be sent within microseconds of each other. The timeout should not matter. If one byte can be read, then the other should follow.
Catering for autobaud requires a bit of fiddling in the synchronisation process, which makes the synchronisation more complex. Urboot bootloaders can gobble up the first sync request from AVRDUDE in order to determine and set the baud rate. However, sometimes the first sync request is gobbled up by the board needing longer than expected to come out of reset (this is what -xdelay=... can correct). There is careful draining that happens to get both sides into synchronisation.
@mcuee In this case I find the way you present the tests confusing and hard to process. This comment says "But it does not work very well" without giving an indication what does not work, followed by many lines of -v` output that seem to indicate all works well?
However, I can not get urboot hex file to work.
I suspect you picked a pre-compiled bootloader with the wrong TX and RX pins of the board? You need to compile this one.
Please edit comments when they give the wrong conclusions. As the comments stay for a long time, people who come here from a search engine may be mislead...
mcuee
commented
1 year ago @stefanrueger
Sorry for the confusion. As mentioned, I do not have good testing facility for the ATtiny chips to run optiboot/urboot. This board is not very good for Optiboot/urboot -- it is difficult to go into the bootloader after flashing the blinking LED sketch. So the easies way is to flash the bootloader everytime for the testing. It is more meant to run Micronucleus bootloader.
I have deleted two messages and edited the remaining messgaes. Please check if there are still confusions or not. Thanks.
More info about the botad -- MH-Tiny ATtiny88 board (Nano formfactor).
stefanrueger
commented
1 year ago the pre-compiled bootloader and they do not seem to work for my board
The Attiny88 has no "designated" communication pins as it has no USART; in that case the pre-compiled urboot bootloader assumes RX=PB0 and TX=PB1 and you'd either have to hook up comms with the host at PB0/PB1 or, if the board has an USB/serial converter, compile the bootloader to use the correct pins of the particular board.
stefanrueger
commented
1 year ago Thanks for clarifying the tests and how you got there, @mcuee. Off topic: I am also pleased to learn that urboot has been tested to work well with ATtiny88. Also good to know the MH Tiny board has LED=AtmelPD0 LEDPOLARITY=1 SWIO=1 TX=AtmelPD6 RX=AtmelPD7. I can create pre-compiled bootloaders for that board...
mcuee
commented
1 year ago the pre-compiled bootloader and they do not seem to work for my board
The Attiny88 has no "designated" communication pins as it has no USART; in that case the pre-compiled urboot bootloader assumes RX=PB0 and TX=PB1 and you'd either have to hook up comms with the host at PB0/PB1 or, if the board has an USB/serial converter, compile the bootloader to use the correct pins of the particular board.
It does not have USB Serial Converter on-board. And I did use PB0/PB1 as well. I tend to think the issue is with 1s WDT timeout.
mcuee
commented
1 year ago Thanks for clarifying the tests and how you got there, @mcuee.
Off topic: I am also pleased to learn that urboot has been tested to work well with ATtiny88. Also good to know the MH Tiny board has
LED=AtmelPB0 LEDPOLARITY=1 SWIO=1 TX=AtmelPD6 RX=AtmelPD7. I can create pre-compiled bootloaders for that board...
That will be good. I will suggest you create two versions, one with WDT=8s (for people who do not have a proper USB-TTL converter with DTR pin and not able to hook up proper reset circuitry) and the other with WDT=1s (for people who can hook-up proper reset circuitry with the USB-to-TTL converter DTR pin and 0.1uF autoreset capacitor).
The good thing of using TX=AtmelPD6 RX=AtmelPD7 is that it is what ATTinyCore uses.
stefanrueger
commented
1 year ago And I did use PB0/PB1 as well
Ahh - OK. Understood. I looked at the differences of what is working (TX=AtmelPD6 RX=AtmelPD7) and what was not (TX=AtmelPB1 RX=AtmelPB0), so concluded that was the issue. So, the only board-specific thing is the position of the LED (PD0, not PB0 as you compiled the urboot bootloader for). What's the LED polarity? Is it low-active or high-active?
| two versions, one with WDT=8s [and] 1s
About time I thought about how to use the template versions of urboot bootloaders. Their binary are done in a way, so that the LED pin, LED polarity, WDTO, TX, RX can be recognised and exchanged in the binary. I have an urloader sketch for a ProMini that acts as bootloader programmer, which creates the right bootloader and correct fuses. Need to publish that.
Maybe I can transfer that idea to AVRDUDE that then can patch bootloaders on the fly for these things. One of the ideas for v8.0 ...
mcuee
commented
1 year ago @stefanrueger
Yes you are rgth that LED pin is PD0 and it is high active.
stefanrueger
commented
1 year ago @mariusgreuel
I now can reproduce the issue in Linux with the FTDI USB/serial converter. Turns out the read timeout of 10 ms is cutting it too fine for the FTDI. See PR #1246
mcuee
commented
1 year ago @stefanrueger and @mariusgreuel
Did you change the default latency timer of your FTDI adapter from 16ms to 1ms?
That is the first thing I do after reading the above advice from Dr Azzy.
@mariusgreuel Maybe you can make that the default for avrdude-libftdi.
stefanrueger
commented
1 year ago @mcuee Great shout! I had not known FTDI has a default latency of 16 ms. Actually, I had not imagined that such a parameter existed, let alone is set to 16 ms per default! One never ceases to learn....
This must be the reason why the FTDI didn't work: I can confirm that setting a receive timeout of 16 ms just about works (15 ms does not), so I set it to 25 ms in PR #1246 to have a margin.
I still think urclock.c should increase its receive timeout for establishing a sync as there will be users who do not know which chip is used to manage the USB/serial conversion, let alone about the default latency timer of the FTDI, let alone that it's 16 ms, let alone that it is not useful on this occasion, let alone how it can be changed.
stefanrueger
commented
1 year ago OK, there might still be issues with Windows around the fact that timeouts behave differently so I leave the subject of this issue and await @mariusgreuel's response to whether PR #1246 significantly changes the experienced issues.
mcuee
commented
1 year ago I still think urclock.c should increase its receive timeout for establishing a sync as there will be users who do not know which chip is used to manage the USB/serial conversion, let alone about the default latency timer of the FTDI, let alone that it's 16 ms, let alone that it is not useful on this occasion, let alone how it can be changed.
@stefanrueger Totally agree with you here. I think PR #1246 should be safe to merge.
OK, there might still be issues with Windows around the fact that timeouts behave differently so I leave the subject of this issue and await @mariusgreuel's response to whether PR https://github.com/avrdudes/avrdude/pull/1246 significantly changes the experienced issues.
I agree with you here as well. Let's wait for the investigation from @mariusgreuel here.
I will see if I can reproduce the issue with ATTiny167 under Windows.
mcuee
commented
1 year ago @mariusgreuel would like to work on #1186 as well.
@stefanrueger, @MCUdude and @dl8dtl So we may have to wait a bit for the final 7.1 release to resolve #1245 and #1186. I think that is perfectly fine. @dl8dtl is carrying out some real HW tests as well.
mcuee
commented
1 year ago I now can reproduce the issue in Linux with the FTDI USB/serial converter. Turns out the read timeout of 10 ms is cutting it too fine for the FTDI. See PR #1246
@stefanrueger Interestingly I can not reproduce the issue with a Nano ATmega328P clone with FT232RL USB to Serial chip on board, even with 16ms latency timer.
But you can see the performance difference between 16ms latency timer and 1ms latency timer from the below testing results. Using 1ms latency timer saves 50% of the flash reading time in this test.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM7 -p m328p
-U flash:r:nano_ft232rl_blink_readback_16ms_latency.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: reading flash memory ...
Reading | ################################################## | 100% 7.68 s
avrdude: writing output file nano_ft232rl_blink_readback_16ms_latency.hex
avrdude done. Thank you.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM7 -p m328p
-U flash:r:nano_ft232rl_blink_readback_1ms_latency.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: reading flash memory ...
Reading | ################################################## | 100% 3.61 s
avrdude: writing output file nano_ft232rl_blink_readback_1ms_latency.hex
avrdude done. Thank you.PR #1246 is still good to go as it does not impact the performance, no regression either.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1246 -c urclock -P COM7 -p m328p
-U flash:r:nano_ft232rl_blink_readback_1ms_latency.hex:i
avrdude_pr1246: AVR device initialized and ready to accept instructions
avrdude_pr1246: device signature = 0x1e950f (probably m328p)
avrdude_pr1246: reading flash memory ...
Reading | ################################################## | 100% 3.58 s
avrdude_pr1246: writing output file nano_ft232rl_blink_readback_1ms_latency.hex
avrdude_pr1246 done. Thank you.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1246 -c urclock -P COM7 -p m328p
-U flash:r:nano_ft232rl_blink_readback_16ms_latency.hex:i
avrdude_pr1246: AVR device initialized and ready to accept instructions
avrdude_pr1246: device signature = 0x1e950f (probably m328p)
avrdude_pr1246: reading flash memory ...
Reading | ################################################## | 100% 7.68 s
avrdude_pr1246: writing output file nano_ft232rl_blink_readback_16ms_latency.hex
avrdude_pr1246 done. Thank you.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1246 -c urclock -P COM7 -p m328p -xshowall
avrdude_pr1246: AVR device initialized and ready to accept instructions
00006420797a 2022-06-10 21.21 Blink.ino.standard.hex 924 store 31298 meta 34 boot 512
u7.7 weu-hprac vector 0 (RESET) ATmega328PI now can reproduce the issue in Linux with the FTDI USB/serial converter. Turns out the read timeout of 10 ms is cutting it too fine for the FTDI. See PR #1246
@stefanrueger
Even though I can not reproduce the issue under WIndows, I can reproduce the issue under Linux. And PR #1246 is good to fixx the issue. But in this case, @mariusgreuel's issue may not be related to FTDI adpater 16ms latency timer.
mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ ./avrdude -c urclock -P /dev/ttyUSB0 -p m328p
-U flash:r:nano_ft232rl_blink_readback_16ms_latency.hex:i
avrdude error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude error: initialization failed, rc=-1
- double check the connections and try again
- use -B to set lower ISP clock frequency, e.g. -B 125kHz
- use -F to override this check
avrdude error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude done. Thank you.
mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ ./avrdude_pr1246 -c urclock -P /dev/ttyUSB0 -p m328p
-U flash:r:nano_ft232rl_blink_readback_16ms_latency.hex:i
avrdude_pr1246: AVR device initialized and ready to accept instructions
avrdude_pr1246: device signature = 0x1e950f (probably m328p)
avrdude_pr1246: reading flash memory ...
Reading | ################################################## | 100% 6.90 s
avrdude_pr1246: writing output file nano_ft232rl_blink_readback_16ms_latency.hex
avrdude_pr1246 done. Thank you.And if I change the latency timer to 1ms, then the issue goes away for git main as well. PR #1246 is still good. We can also see that Linux has a bit of better performance compared to Windows. Take note this is on the same Acer laptop (dual boot Windows 11 and Ununtu Linux 20.04)
mcuee@UbuntuSwift3:~$ sudo su
root@UbuntuSwift3:/home/mcuee# echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
root@UbuntuSwift3:/home/mcuee# exit
exit
mcuee@UbuntuSwift3:~$ cd build/avr/avrdude_bin/
mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ ./avrdude_pr1246 -c urclock -P /dev/ttyUSB0 -p m328p
-U flash:r:nano_ft232rl_blink_readback_1ms_latency.hex:i
avrdude_pr1246: AVR device initialized and ready to accept instructions
avrdude_pr1246: device signature = 0x1e950f (probably m328p)
avrdude_pr1246: reading flash memory ...
Reading | ################################################## | 100% 3.07 s
avrdude_pr1246: writing output file nano_ft232rl_blink_readback_1ms_latency.hex
avrdude_pr1246 done. Thank you.
mcuee@UbuntuSwift3:~/build/avr/avrdude_bin$ ./avrdude -c urclock -P /dev/ttyUSB0 -p m328p
-U flash:r:nano_ft232rl_blink_readback_1ms_latency.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: reading flash memory ...
Reading | ################################################## | 100% 3.08 s
avrdude: writing output file nano_ft232rl_blink_readback_1ms_latency.hex
avrdude done. Thank you.
@stefanrueger Going back to the original report from @mariusgreuel, I am wondering two things. 1) Just wondering why you are not using the HW UART (RX=AtmelPA0, TX=AtmelPA1) for this paticular bootloader. Is this because you want to save the HW UART for the user? 2) Just wondering if 115200bps is too fast for Firmware UART?
@mariusgreuel
Hopefully PR #1246 may help. If not, please help to see if you can try the following things, 1) Can you try the lower baudrate urboot firmware, like 19200bps to see if that helps? 2) You may also want to try Optiboot FW from ATTinyCore for your FTDI converter to see if there is an issue or not. This is just for troubleshooting purpose. https://github.com/SpenceKonde/ATTinyCore 3) The other thing is to see if you can build urboot firmware with HW UART (RX=AtmelPA0, TX=AtmelPA1)? If you do not have DTR reset in place, you may also need to use 8s for rhe watchdog timeout.
stefanrueger
commented
1 year ago @mcuee
The ATtiny167 has a somewhat non-standard UART which is not picked up by the USART interface in urboot.c. (Need looking into at the urboot project.) So, alas, there is no UART support for this part.
I have tried the urboot_digisparkpro_16mhz_115200bps_rxb6_txb3_led+b1_ur_vbl.hex with manual reset (release reset; start programming within one second) from this directory and can confirm it works fine with 115200 baud under Linux with an FTDI USB/serial converter once PR #1246 was applied.
mariusgreuel
commented
1 year ago I switched from Windows to a raspi/Ubuntu, and with the latest timing changes, I still have communication problems depending on the serial adapter I am using.
For instance, here is the output of a genuine FT232H adapter:
pi@raspi:~/repos/avrdude/build_linux/src $ ./avrdude -c urclock -p t167 -P /dev/ttyUSB0 -vvvv
avrdude: Version 7.0-20221229 (0f956e9)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /home/pi/repos/avrdude/build_linux/src/avrdude.conf
User configuration file is /home/pi/.avrduderc
User configuration file does not exist or is not a regular file, skipping
avrdude: libreadline is used; avrdude -t -c urclock should work interactively
Using Port : /dev/ttyUSB0
Using Programmer : urclock
avrdude: 245 ms: enter urclock_getsync()
avrdude: send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: 270 ms: sleeping for 32 ms
avrdude: send: [20] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: 327 ms: sleeping for 64 ms
avrdude: send: [20] [20]
avrdude: recv: . [00] . [ea]
avrdude: send: [20] [20]
avrdude: recv: . [fc] [20]
avrdude: send: [20] [20]
avrdude: recv: . [1d] [20]
avrdude: send: [20] [20]
avrdude: recv: . [1d] [20]
avrdude: send: [20]
avrdude: recv: . [1d]
avrdude set_uP() [urclock.c:1054] warning: uP_table does not know mcuid 1306
avrdude: 459 ms: all good, ready to rock
AVR Part : ATtiny167
Chip Erase delay : 15000 us
RESET disposition : possible i/o
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 10 4 0 no 512 4 0 4000 4500 0xff 0xff
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
flash 65 10 64 0 yes 16384 128 128 4500 4500 0xff 0xff
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lfuse 0 0 0 0 no 1 1 0 9000 9000 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
hfuse 0 0 0 0 no 1 1 0 9000 9000 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
efuse 0 0 0 0 no 1 1 0 9000 9000 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lock 0 0 0 0 no 1 1 0 9000 9000 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
calibration 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Programmer Type : Urclock
Description : Urclock programmer for urboot bootloaders using urprotocol
Urboot protocol for ATtiny167
avrdude: send: P [50] [20]
avrdude: ser_recv(): programmer is not responding
avrdude urclock_recv() [urclock.c:1923] error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude main() [main.c:1246] error: initialization failed, rc=-1
- double check the connections and try again
- use -B to set lower ISP clock frequency, e.g. -B 125kHz
- use -F to override this check
avrdude: send: Q [51] [20]
avrdude: ser_recv(): programmer is not responding
avrdude urclock_recv() [urclock.c:1923] error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude done. Thank you.I produced the output using a manual-reset method. The urclock clock seems to be quite sensitive on when the bootloader starts. When I release the reset button while avrdude is already running, I can create a >50% failure rate.
mariusgreuel
commented
1 year ago Have you tried to set and vary -xdelay=100
I have both tried -xdelay and -xstrict, but I did not notice any differences
Does your USB/serial chip reset the board when RTS/DTS is plucked?
I have a Arduino Nano clone with a m168p and a CH340 on it and that worked fine.
The t167 board I am currently resetting manually.
mariusgreuel
commented
1 year ago Maybe you can make that the default for avrdude-libftdi.
Good catch. I was aware of the 16ms latency, but I did not connect the dots. I tried it on my Windows machine, and it did not really seem to help.
As libftdi goes, I do not think the latency timer applies to bit-bang/MPSSE mode. There are some differences in the D2XX drivers compared to libftdi/libusb solution that I had to work around, however, it never occurred to me to change the latency timer. I will try to remember that the next time I play with that.
mariusgreuel
commented
1 year ago Just wondering why you are not using the HW UART (RX=AtmelPA0, TX=AtmelPA1) for this paticular bootloader. Is this because you want to save the HW UART for the user?
As the Digispark boards were mentioned on Stefans urboot page, I just grabbed the hex files from there. Plus, as some board require tweaking the fuses, I did not want to mess up my expensive Arduino boards, and turned to the cheap clones :-).
Just wondering if 115200bps is too fast for Firmware UART?
Yes, 115k is on the edge of what a 16MHz AVR can do reliably. But then, these are the bootloaders linked from the README.
@stefanrueger
BTW, I could not make the Digispark T85 clones work at all. They do not need different fuse settings, do they? Out of the box, they run at 16MHz off the PLL, I think (16.5MHz with the micronucleus bootloader active, I believe). Here, I think the 115k baud-rate combined with a PLL/RC oscillator may push it over the edge, not sure.
mcuee
commented
1 year ago Maybe you can make that the default for avrdude-libftdi.
Good catch. I was aware of the 16ms latency, but I did not connect the dots. I tried it on my Windows machine, and it did not really seem to help.
This is kind of in-line with my expectation based on my testing of FT232RL based Nano Atmega328P Clone. The latency timer somehow does not cause the issue under Windows even though it causes issue under Linux before the merge of PR #1246.
As libftdi goes, I do not think the latency timer applies to bit-bang/MPSSE mode.
I believe that is correct.
There are some differences in the D2XX drivers compared to libftdi/libusb solution that I had to work around, however, it never occurred to me to change the latency timer. I will try to remember that the next time I play with that.
That will be great. It is not urgent so take your time to work on avrdude-libftdi.
mcuee
commented
1 year ago Just wondering why you are not using the HW UART (RX=AtmelPA0, TX=AtmelPA1) for this paticular bootloader. Is this because you want to save the HW UART for the user?
As the Digispark boards were mentioned on Stefans urboot page, I just grabbed the hex files from there. Plus, as some board require tweaking the fuses, I did not want to mess up my expensive Arduino boards, and turned to the cheap clones :-).
Just wondering if 115200bps is too fast for Firmware UART?
Yes, 115k is on the edge of what a 16MHz AVR can do reliably. But then, these are the bootloaders linked from the README.
You can try other baud rate here, like 19200bps and 38400bps https://github.com/stefanrueger/urboot/tree/main/bootloaders/board_digispark-pro/fcpu_16mhz
@stefanrueger
BTW, I could not make the Digispark T85 clones work at all. They do not need different fuse settings, do they? Out of the box, they run at 16MHz off the PLL, I think (16.5MHz with the micronucleus bootloader active, I believe). Here, I think the 115k baud-rate combined with a PLL/RC oscillator may push it over the edge, not sure.
Again you can try 19200bps and 38400bps urboot hex files here. https://github.com/stefanrueger/urboot/tree/main/bootloaders/board_digispark/fcpu_16mhz
mcuee
commented
1 year ago I produced the output using a manual-reset method. The urclock clock seems to be quite sensitive on when the bootloader starts. When I release the reset button while avrdude is already running, I can create a >50% failure rate.
@stefanrueger and @mariusgreuel
Unfortunately I have zero success with DigiSpark Pro ATtiny167 with either an FTDI FT232RL adapter or a CH340 adapter, under Linux and Windows. I tried two boards and I tried 19200bps FW. I am using manually reset as well. So I gave up today.
Both are cheap ones bought from Taobao (China version of AliExpress) so maybe there are other issues. Still Micronucleus bootloader works fine.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p t167
-U .\urboot_digispark-pro_16mhz_19200bps_rxb6_txb3_ee_led+b1_fr_ce_ur_vbl.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9487 (probably t167)
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 .\urboot_digispark-pro_16mhz_19200bps_rxb6_txb3_ee_led+b1_fr_ce_ur_vbl.hex for flash
with 370 bytes in 2 sections within [0x3e80, 0x3fff]
using 3 pages and 14 pad bytes
avrdude: writing 370 bytes flash ...
Writing | ################################################## | 100% 0.03 s
avrdude: 370 bytes of flash written
avrdude: verifying flash memory against .\urboot_digispark-pro_16mhz_19200bps_rxb6_txb3_ee_led+b1_fr_ce_ur_vbl.hex
Reading | ################################################## | 100% 0.01 s
avrdude: 370 bytes of flash verified
avrdude done. Thank you.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p t167 -qqt
avrdude> dump lfuse
0000 ff |. |
avrdude> dump hfuse
0000 d4 |. |
avrdude> dump efuse
0000 fe |. |
avrdude> quit
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM6 -b 19200 -p t167 -v
avrdude: Version 7.0-20221229 (0f956e9)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\work\avr\avrdude_test\avrdude_bin\avrdude.conf
Using Port : COM6
Using Programmer : urclock
Overriding Baud Rate : 19200
avrdude urclock_getsync() warning: attempt 1 of 10: not in sync
avrdude urclock_recv() error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude urclock_getsync() warning: attempt 2 of 10: not in sync
avrdude urclock_recv() error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude urclock_getsync() warning: attempt 3 of 10: not in sync
avrdude urclock_recv() error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude urclock_getsync() warning: attempt 4 of 10: not in sync
avrdude urclock_recv() error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude urclock_getsync() warning: attempt 5 of 10: not in sync
avrdude urclock_recv() error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude urclock_getsync() warning: attempt 6 of 10: not in sync
avrdude urclock_recv() error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude urclock_getsync() warning: attempt 7 of 10: not in sync
avrdude urclock_recv() error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude urclock_getsync() warning: attempt 8 of 10: not in sync
avrdude urclock_recv() error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude urclock_getsync() warning: attempt 9 of 10: not in sync
avrdude urclock_recv() error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude urclock_getsync() warning: attempt 10 of 10: not in sync
avrdude urclock_recv() error: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude main() error: unable to open programmer urclock on port COM6
avrdude done. Thank you.
Same thing under Linux. I have tried the urboot hex files and I also tried the following 4 hex files I built from source.
The board has 16MHz crystal.
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ ls *.hex
attiny167_16mhz_115200bps_ev1f7_swio1_txPB3_rxPB6_ledPB1_wdto1s_ur.hex
attiny167_16mhz_115200bps_ev1f7_swio1_txPB3_rxPB6_ledPB1_wdto8s_ur.hex
attiny167_16mhz_19200bps_ev1f7_swio1_txPB3_rxPB6_ledPB1_wdto1s_ur.hex
attiny167_16mhz_19200bps_ev1f7_swio1_txPB3_rxPB6_ledPB1_wdto8s_ur.hexWhen I release the reset button while avrdude is already running, I can create a >50% failure rate.
@mariusgreuel I recommend to first release reset; then press enter on the pre-typed command line avrdude -c urclock .... within the WDTO time.
I have tried the urboot hex files and I also tried the following 4 hex files I built from source
@mcuee The output you get is symptomatic of "dead" pins. Maybe change the RX/TX pins? If one of them is not led out on the board or blown that won't work. You mentioned that micronucleus works. Try using the RX/TX lines that are used in that bootloader?
@mcuee and @mariusgreuel
I wonder whether a hardware-pullup on rx (FTDI-side) = tx (AVR side) helps? The neatly documented runs tell me that the comms is as it should be, just that avrdude receives some garbage initially from the AVR.
| notice there is still a ser_recv(): programmer is not responding
ser_recv() timing out is part and parcel of the synchronisation comms and is expected. This is owing to potential autobaud gobbling up stuff and to urclock.c's best attempt to deal with all sorts of shenannigans that different optiboot version from 4.4 to 8.3 have thrown avrdude's way over the years (eg, optiboot enabling the USART then 300 ms not listening to it (whilst flashing lights) can kill the first byte of AVRDUDE's 2-byte get_sync command; optiboot's WDT reset loops due to its desire to keep the reset cause in R2 as best as possible; etc).
Basically -c urclock expects (for this MCU) the response of 0x20 0x1d in quick succession that ID's the ATTiny167 plus a few bootloader proerties. In the failing case the comms is out of step by one byte and it receives 0x1d 0x20, but not in quick succession. Somehow draining/time out that is designed to get comms back in sync does not work here. I cannot tell whether this is a property of the FTDI, Windows, or a combination.
In the meantime I will reflect on whether a modification of the protocol might be able to deal with initial garbage and/or a Windows ser_recv() that tells me 2 bytes were received (but only one was) though that is a challenging task! (All of this should not be rushed, though, and I wouldn't want to change the tried and tested sync routine just before a release.)
stefanrueger
commented
1 year ago BTW, I could not make the Digispark T85 clones work at all. They do not need different fuse settings, do they? Out of the box, they run at 16MHz off the PLL, I think (16.5MHz with the micronucleus bootloader active, I believe). Here, I think the 115k baud-rate combined with a PLL/RC oscillator may push it over the edge, not sure.
I had a digispark ATtiny85 running with v7.x urboot some time ago. I don't think I needed to change fuses. MHz are MHz. Is the problem that the PLL-generated F_CPU tends to have a higher F_CPU error than otherwise? If so, might try compiling with F_CPU=16500000L ...
Most of my (vvv limited) different AVRs run with 16 MHz. All run with 115200 bootloading, either USART or SW I/O (on parts without USART). My 8 MHz boards need SW I/O as the classic AVR USART baud rate divisor generates a too high quantisation error for 115,200 baud; SW I/O allows a finer granularity here.
mcuee
commented
1 year ago @mcuee The output you get is symptomatic of "dead" pins. Maybe change the RX/TX pins? If one of them is not led out on the board or blown that won't work. You mentioned that micronucleus works. Try using the RX/TX lines that are used in that bootloader?
@stefanrueger
Thanks. I managed to get Optiboot working first on my board. And it is using PA1/PA0 (HW UART pin). So I rebuild urboot using SW UART with PA1/PA0. Now it works under Linux. I will test WIndows later. This is using an FT232RL based USB-TTL converter.
I set the WDTO=8S to make it easier to use manual reset method.
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ make MCU=attiny167 F_CPU=16000000L URPROTOCOL=1 SWIO=1 TX=AtmelPA1 RX=AtmelPA0 VBL=1 LED=AtmelPB1 FRILLS=7 WDTO=8S BAUD_RATE=115200
./avr-toolchain/5.4.0/bin/avr-gcc -DSTART=0x3e80UL -DRJMPWP=0xcfd6 -Wl,--section-start=.text=0x3e80 -Wl,--section-start=.version=0x3ffa -D_urboot_AVAILABLE=26 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=attiny167 -DF_CPU=16000000L -Wno-clobbered -DWDTO=8S -DBAUD_RATE=115200 -DLED=AtmelPB1 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=1 -DSWIO=1 -DTX=AtmelPA1 -DRX=AtmelPA0 -Wl,--relax -nostartfiles -nostdlib -o attiny167_16mhz_115200bps_ev1f7_swio1_txPA1_rxPA0_ledPB1_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 attiny167_16mhz_115200bps_ev1f7_swio1_txPA1_rxPA0_ledPB1_wdto8s_ur.elf attiny167_16mhz_115200bps_ev1f7_swio1_txPA1_rxPA0_ledPB1_wdto8s_ur.hex
./avr-toolchain/5.4.0/bin/avr-objdump -h -S attiny167_16mhz_115200bps_ev1f7_swio1_txPA1_rxPA0_ledPB1_wdto8s_ur.elf > attiny167_16mhz_115200bps_ev1f7_swio1_txPA1_rxPA0_ledPB1_wdto8s_ur.lst
-- 372 384 u7.7 weu-jPr-c attiny167_16mhz_115200bps_ev1f7_swio1_txPA1_rxPA0_ledPB1_wdto8s_ur.hex
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c usbasp -p t167 -U attiny167_16mhz_115200bps_ev1f7_swio1_txPA1_rxPA0_ledPB1_wdto8s_ur.hex -qq && echo OK
OK
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c urclock -P /dev/ttyUSB0 -p t167 -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-jPr-c vector 16 (EE_RDY) ATtiny167attiny167_16mhz_115200bps_ev1f7_swio1_txPA1_rxPA0_ledPB1_wdto8s_ur.zip
mcuee
commented
1 year ago @stefanrueger
And it actually works well under WIndows as well.
I tested with both 1ms and 16ms FTDI latency timer settings. You can see the latency timer plays a big part in the flash read/write speed.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM7 -p t167 -xshowall
avrdude: 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 16 (EE_RDY) ATtiny167
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM7 -p t167 -U .\Blink_t167.ino.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9487 (probably t167)
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_t167.ino.hex for flash
with 738 bytes in 1 section within [0, 0x2e1]
using 6 pages and 30 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 738 bytes flash ...
Writing | ################################################## | 100% 0.20 s
avrdude: 738 bytes of flash written
avrdude: verifying flash memory against .\Blink_t167.ino.hex
Reading | ################################################## | 100% 0.21 s
avrdude: 738 bytes of flash verified
avrdude done. Thank you.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM7 -p t167 -xshowall
avrdude: AVR device initialized and ready to accept instructions
0000ffffffff 2022-12-28 17.49 Blink_t167.ino.hex 738 store 15232 meta 30 boot 384
u7.7 weu-jPr-c vector 16 (EE_RDY) ATtiny167
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM7 -p t167 -U flash:r:urboot_t167_16ms_latency_read.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9487 (probably t167)
avrdude: reading flash memory ...
Reading | ################################################## | 100% 4.16 s
avrdude: writing output file urboot_t167_16ms_latency_read.hex
avrdude done. Thank you.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM7 -p t167 -U flash:r:urboot_t167_1ms_latency_read.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9487 (probably t167)
avrdude: reading flash memory ...
Reading | ################################################## | 100% 1.92 s
avrdude: writing output file urboot_t167_1ms_latency_read.hex
avrdude done. Thank you.
@mariusgreuel
You may want to give the above a try. With WTDO=8S, it is much easier to use with manual reset method.
mcuee
commented
1 year ago I had a digispark ATtiny85 running with v7.x urboot some time ago. I don't think I needed to change fuses. MHz are MHz. Is the problem that the PLL-generated F_CPU tends to have a higher F_CPU error than otherwise? If so, might try compiling with F_CPU=16500000L ...
@stefanrueger
Indeed this seems to work under Linux. There is no reset button so I just burn the bootloader and run with -c urclock. I will test Windows later. BTW, I tried 38400bps and 115200bps and both do not work.
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ make MCU=attiny85 F_CPU=16500000L MCU=attiny85 URPROTOCOL=1 SWIO=1 TX=AtmelPB3 RX=AtmelPB4 VBL=1 FRILLS=7 WDTO=8S BAUD_RATE=19200
./avr-toolchain/5.4.0/bin/avr-gcc -DSTART=0x1e80UL -DRJMPWP=0xcfd7 -Wl,--section-start=.text=0x1e80 -Wl,--section-start=.version=0x1ffa -D_urboot_AVAILABLE=24 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=attiny85 -DF_CPU=16500000L -Wno-clobbered -DWDTO=8S -DBAUD_RATE=19200 -DDUAL=0 -DEEPROM=1 -DURPROTOCOL=1 -DFRILLS=7 -DVBL=1 -DSWIO=1 -DTX=AtmelPB3 -DRX=AtmelPB4 -Wl,--relax -nostartfiles -nostdlib -o attiny85_16500khz_19200bps_ev1f7_swio1_txPB3_rxPB4_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 attiny85_16500khz_19200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.elf attiny85_16500khz_19200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex
./avr-toolchain/5.4.0/bin/avr-objdump -h -S attiny85_16500khz_19200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.elf > attiny85_16500khz_19200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.lst
-- 374 384 u7.7 weu-jPr-c attiny85_16500khz_19200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c usbasp -p t85 -qqt
avrdude> dump lfuse
0000 f1 |. |
avrdude> dump hfuse
0000 df |. |
avrdude> dump efuse
0000 fe |. |
avrdude> quit
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c usbasp -p t85 -U attiny85_16500khz_19200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex -qq && echo OK
OK
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c urclock -p t85 -P /dev/ttyUSB1 -b 19200 -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-jPr-c vector 6 (EE_RDY) ATtiny85attiny85_16500khz_19200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.zip
mcuee
commented
1 year ago And indeed it is okay under Windows as well. I can see the LED is blinking.
@mariusgreuel You may want to give the above hex file a try.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p t85
-U .\attiny85_16500khz_19200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM7 -b 19200 -p t85 -xshowall
avrdude: 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 6 (EE_RDY) ATtiny85
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p t85 -U .\attiny85_16500khz_19200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM7 -b 19200 -p t85
-U .\Blink.ino_t85.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e930b (probably t85)
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.ino_t85.hex for flash
with 542 bytes in 1 section within [0, 0x21d]
using 9 pages and 34 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 542 bytes flash ...
Writing | ################################################## | 100% 0.48 s
avrdude: 542 bytes of flash written
avrdude: verifying flash memory against .\Blink.ino_t85.hex
Reading | ################################################## | 100% 0.41 s
avrdude: 542 bytes of flash verified
avrdude done. Thank you.
@mcuee Thanks for testing. Looks like the t85 board has a tricky frequency. Any way you can measure it? Like measuring the timing of a blink sketch with an osci (or another board with a halfway reliable quartz). If you use the measured real frequency as F_CPU=....L argument then 115200 baud *should* work. At 16 MHz there are ~139 cycles per bit. The SW I/O in urboot.c tries to match the required cycles, so there is a quanitisation error of ~ 1/139 < 1%. That should be OK. But if the real frequency deviates from the compiled-for frequency by another 2% one might get into trouble...
mcuee
commented
1 year ago @mcuee Thanks for testing. Looks like the t85 board has a tricky frequency. Any way you can measure it? Like measuring the timing of a blink sketch with an osci (or another board with a halfway reliable quartz). If you use the measured real frequency as
F_CPU=....Largument then 115200 baud*should*work. At 16 MHz there are ~139 cycles per bit. The SW I/O inurboot.ctries to match the required cycles, so there is a quanitisation error of ~ 1/139 < 1%. That should be OK. But if the real frequency deviates from the compiled-for frequency by another 2% one might get into trouble...
I have three weeks' of long vacation this December. I will try to measure the frequency next week when I am back to work.
I will test 8MHz and 16MHz clock settings as well.
mcuee
commented
1 year ago I will test 8MHz and 16MHz clock settings as well.
@stefanrueger
Both do not work, tested with 19200bps and 115200bps. So probably the clock is the issue as you mentioned.
Edit: hmm, later I got 115200bps working for 16MHz PLL clock; and 57600bps working with 8MHz internal RC oscillator..
stefanrueger
commented
1 year ago raspi/Ubuntu, and with the latest timing changes, I still have communication problems depending on the serial adapter
Thanks for reporting this. @mariusgreuel I'll try to think about what happens when avrdude reads arbitrary data before the board gets into the bootloader. Maybe -c urclock can do sth to be more robust against this kind of scenario... Knowing whether a HW pullup on the AVR TX helps would be good.
stefanrueger
commented
1 year ago probably the clock is the issue
The overall comms error is compounded by sender quantisation error, sender freq error, receiver quantisation error, receiver freq error, then multiplied by 10 bits per byte. That shouldn't go beyond a quarter bit, so a 2% clock error on one side may well ruin the comms (irrespective of UART or SW I/O).
So, what's the story of a t85 F_CPU? What kind of error can we expect? Even a terrible 1000 ppm ceramic resonator "only" has a clock error of 0.1% (negligible for serial errors).
mcuee
commented
1 year ago probably the clock is the issue
The overall comms error is compounded by sender quantisation error, sender freq error, receiver quantisation error, receiver freq error, then multiplied by 10 bits per byte. That shouldn't go beyond a quarter bit, so a 2% clock error on one side may well ruin the comms (irrespective of UART or SW I/O).
So, what's the story of a t85 F_CPU? What kind of error can we expect? Even a terrible 1000 ppm ceramic resonator "only" has a clock error of 0.1% (negligible for serial errors).
My paticular ATTiny85 board is using the internal RC oscillator. FYI, I could not get Optiboot working either.
It seems to me my board may runnling at a frequency closer to 16.5MHz than the norminal 16MHz.
Working configuration fuse settings:
avrdude> dump lfuse
0000 f1 |. |
avrdude> dump hfuse
0000 df |. |
avrdude> dump efuse
0000 fe |. |The ATTiny167 board has 16MHz external crystal.
mcuee
commented
1 year ago It seems to me my board may runnling at a frequency closer to 16.5MHz than the norminal 16MHz.
@stefanrueger
I believe this is true.
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c usbasp -p t85
-U ./attiny85_16500khz_115200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex -qq && echo OK
OK
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ avrdude -c urclock -p t85 -P /dev/ttyUSB1 -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-jPr-c vector 6 (EE_RDY) ATtiny85Hmm, now it works with all the following hex files. I think you are right 115200bps can work with the board.
mcuee@UbuntuSwift3:~/build/avr/urboot/src$ ls *.hex
attiny85_16100khz_115200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex
attiny85_16200khz_115200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex
attiny85_16300khz_115200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex
attiny85_16400khz_115200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex
attiny85_16500khz_115200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex
attiny85_16mhz_115200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex
attiny85_8mhz_57600bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hexFor 8MHz internal RC oscillator, I can not get 115200bps to work, but 57600bps works fine.
Working hex files are included in the zip file attached attiny85_urboot.zip
mcuee
commented
1 year ago Tested under Windows as well.
1) FT232RL converter (both latency timer of 1ms and 16ms)
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p t85
-U .\attiny85_16mhz_115200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM7 -b 115200 -p t85
-U .\Blink.ino_t85.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e930b (probably t85)
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.ino_t85.hex for flash
with 542 bytes in 1 section within [0, 0x21d]
using 9 pages and 34 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 542 bytes flash ...
Writing | ################################################## | 100% 0.17 s
avrdude: 542 bytes of flash written
avrdude: verifying flash memory against .\Blink.ino_t85.hex
Reading | ################################################## | 100% 0.09 s
avrdude: 542 bytes of flash verified
avrdude done. Thank you.2) CH340 Converter
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p t85
-U .\attiny85_16mhz_115200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM6 -b 115200 -p t85
-U .\Blink.ino_t85.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e930b (probably t85)
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.ino_t85.hex for flash
with 542 bytes in 1 section within [0, 0x21d]
using 9 pages and 34 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 542 bytes flash ...
Writing | ################################################## | 100% 0.17 s
avrdude: 542 bytes of flash written
avrdude: verifying flash memory against .\Blink.ino_t85.hex
Reading | ################################################## | 100% 0.09 s
avrdude: 542 bytes of flash verified
avrdude done. Thank you.
3) PL2303HX converter.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p t85
-U .\attiny85_16mhz_115200bps_ev1f7_swio1_txPB3_rxPB4_wdto8s_ur.hex -qq && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM19 -b 115200 -p t85
-U .\Blink.ino_t85.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e930b (probably t85)
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.ino_t85.hex for flash
with 542 bytes in 1 section within [0, 0x21d]
using 9 pages and 34 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 542 bytes flash ...
Writing | ################################################## | 100% 0.19 s
avrdude: 542 bytes of flash written
avrdude: verifying flash memory against .\Blink.ino_t85.hex
Reading | ################################################## | 100% 0.11 s
avrdude: 542 bytes of flash verified
avrdude done. Thank you.
MCUdude
commented
1 year ago Looks like the t85 board has a tricky frequency. Any way you can measure it? Like measuring the timing of a blink sketch with an osci (or another board with a halfway reliable quartz).
A simple way of measuring the clock frequency is to enable the CKOUT fuse bit. Then the clock signal will be outputted on pin PB4, which can easily be measured using an oscilloscope or a frequency counter.
mcuee
commented
1 year ago A simple way of measuring the clock frequency is to enable the CKOUT fuse bit. Then the clock signal will be outputted on pin PB4, which can easily be measured using an oscilloscope or a frequency counter.
@MCUdude
Nice tip.
Based on my latest test results, in the end the clock frequency is not the issue. I think my problems are mostly related to the use of manual reset. In the end I can not reproduce the issue reported by @mariusgreuel.
I need to have better testing facility for urboot/optiboot. I need to find some components (10k resistors and 100nF capacitors) first and then a few USB-TTL converters with the DTR pin available so that I can have the auto-reset circuitries.
As of now I only have two FTDI adapters with the DTR pin exposed. I have quite a few CH340 adapters but they do not have the exposed DTR pins. They usually have only 5V/TX/RX/GND or 5V/3V3/TX/RX/GND pins. The single PL2303HX adapter does not have the DTR pin either.
I was trying to reuse two damaged Uno Clones with the ATmega328P SMD chips removed. They have the RESET circuitry and RXD/TXD pins. Somehow they do not work. I have not figured out why they do not work yet.
Can you share your test setup for the ATtiny chips?
mcuee
commented
1 year ago @stefanrueger and @mariusgreuel
I think in the end, I can not reproduce the issue under Linux/Windows in the end, other than the issue of FT232 based Nano Clone under Linux which was already addressed by PR #1246.
We will have to wait for more results from @mariusgreuel.
stefanrueger
commented
1 year ago @mariusgreuel Could you try what happens when the serial interface is drained periodically (rather than at the start only):
diff --git a/src/urclock.c b/src/urclock.c
index 7f32d88..e461947 100644
--- a/src/urclock.c
+++ b/src/urclock.c
@@ -1985,6 +1985,7 @@ static int urclock_getsync(const PROGRAMMER *pgm) {
if(!ur.gs.seen || iob[0] != ur.gs.stk_insync || iob[1] != ur.gs.stk_ok || iob[0] == iob[1]) {
ur.gs.stk_insync = iob[0];
ur.gs.stk_ok = iob[1];
+ serial_drain(&pgm->fd, 0); // Drain periodically to guard against initial line noise
ur.gs.seen = 1;
} else
break;
@@ -2247,9 +2248,7 @@ static int urclock_open(PROGRAMMER *pgm, const char *port) {
usleep((125+ur.delay)*1000); // Wait until board starts up accommodating effective drain time
#endif
- // Drain any extraneous input
serial_drain_timeout = 20; // ms
- serial_drain(&pgm->fd, 0);
pmsg_debug("%4ld ms: enter urclock_getsync()\n", avr_mstimestamp());
if(urclock_getsync(pgm) < 0)It is these three bytes that seem to jeopardise the connection. They might be some kind of line noise/garbage/FTDI intialisation artifact, but let's see whether above intervention gets rid of the problem.
mariusgreuel
commented
1 year ago Could you try what happens when the serial interface is drained periodically
@stefanrueger Im the meantime, I came to the same conclusion. I think what happens during a manual-reset communication failure is that there is one extra byte in the RX buffer that enters after you drain the buffer. So the response is [1d][20] instead of [20][1d], with one remaining RX byte not read.
I fixed that by adding this line:
diff --git a/src/urclock.c b/src/urclock.c
index 7f32d88e..49bc9809 100644
--- a/src/urclock.c
+++ b/src/urclock.c
@@ -1978,6 +1978,7 @@ static int urclock_getsync(const PROGRAMMER *pgm) {
* that are strict about the protocol, eg, picoboot, the presence of -xstrict implies that
* comms should use Cmnd_STK_GET_SYNC for getting in sync.
*/
+ serial_drain(&pgm->fd, 0); // Drain periodically to guard against initial line noise
iob[0] = attempt == 0? autobaud_sync: ur.strict? Cmnd_STK_GET_SYNC: Sync_CRC_EOP;
iob[1] = Sync_CRC_EOP;
urclock_send(pgm, iob, 2);With that line in place I have not seen this kind of error anymore, using the t167 board and various serial converters.
BTW, when I set up the RTS auto-reset mechanism, the error disappeared also.
I have two more suggestions:
1) Change this error to a warning:
```console
avrdude error: programmer is not responding; try -xstrict and/or vary -xdelay=100
```2) Print the warning only when run in terminal mode:
```console
avrdude warning: compiled without readline library, cannot use avrdude -t -c urclock interactively
```I am probably going to spend some more time with urboot. I have a project where I hacked some commercial device using a m88p, and there was just not enough space to fit a bootloader. That you managed to squeeze urboot into some 250 bytes is really amazing!
stefanrueger
commented
1 year ago @mariusgreuel Thanks for testing and confirming my hunch. Could you see whether my suggestion also works? I know it sounds counter-intuitive to drop the initial drain and then to periodically drain after receiving (and evaluating!) responses rather than before every request is sent, but
-c urclock works specifically with optiboot v8.3 out of the box without the need to add -xdelay=...; if my suggestion works that would make it easier to calibrate againYour other suggestions are great - let's see how I can implement them
I have been tinkering with urboot on Windows, and there seem to be issues with the bootloader communication.
I set up an Digispark Pro with a ATtiny167 and flashed it with
urboot_digispark-pro_16mhz_115200bps_rxb6_txb3_led+b1_ur_vbl.hex.I am running the command
and get the error
and sometimes
Depending on the USB serial converter I am using, the connection is very unreliable. My trusted FT232H-based serial converter seems to cause the most problems (>50% failure rate), a CP2102-based serial converter seems to work as expected.
The first thing I noticed is that the WIN32 implementation of
ser_recvis broken. Asser_recvdoes not return the number of bytes read, it must return the exact same number of bytes requested or -1 on failure/timeout. When a timeout occurs, the current WIN32ser_recvmay return success, but only a partial amount of bytes requested.urclock_getsyncsets a very short timeout of 10ms, so quite often,ser_recvonly returns one byte instead of two, and everything goes downhill from there.Initially, I thought I can fix this by changing
ser_recvto either receive the full amount of bytes requested or -1 on timeout, but that did not fix it. There seems to be a problem related to the small 10ms timeout, and the FTDI driver sometimes returning zero bytes.Also tried
-xstrict, did not help. I do not think its cabling, signals look good.Using -vvvv and some WIN32 patches, here is a success (notice there is still a
ser_recv(): programmer is not responding)and a failure
Saving further analysis for some other time...