Closed MCUdude closed 1 year ago
stefanrueger
commented
1 year ago Would these baud rates be what you are after for these F_CPU?
if [[ /attiny13/attiny13a/ =~ /$mcu/ ]]; then
baud[9600000]=250000/230400/115200/57600/38400/19200/9600
baud[4800000]=115200/57600/38400/19200/9600
baud[1200000]=38400/19200/9600
baud[600000]=19200/9600
fi
MCUdude
commented
1 year ago That would be excellent! Is 250000 baud the fastest "standard" baudrate the ATtiny13/A can handle without too much error?
stefanrueger
commented
1 year ago Is 250000 baud the fastest "standard" baudrate the ATtiny13/A can handle without too much error?
Yes.
The ATtiny13 does not have a hardware UART. So, F_CPU/baud rate is the budget of clock cycles that the software has for delaying half a bit, sensing the RX bit, then delaying half a bit. 9.6 MHz/250 kbaud gives us 38.4 cycles. That should just about work, but I doubt one can do SWIO with 460800 baud (only 20 cycles for a complex task).
BTW, 38.4 cycles also means an intrinsic quantisation error of 0.4/38.4 ~ 1%, which is OK assuming the internal oscillator does not add more than about 1.5% of frequency deviation. Smaller baud rates have a better quantisation error: for example, at 115200 baud there is a budget of 83.333 cycles where the quantisation error is 0.33/83.33 = 0.4 %, so you can afford the internal oscillator to be off by max 2%.
stefanrueger
commented
1 year ago OK, done: see, eg, ATtiny13A bootloaders
MCUdude
commented
1 year ago Thanks! I'll be away for the weekend, but I'll give it a try next week when I'm back home
stefanrueger
commented
1 year ago I checked my SWIO code for the max baud rate. It is F_CPU/29 for classic parts with 16-bit PC and F_CPU/33 for classic parts with 22-bit PC (ATmega2560, eg). XMEGA parts can achieve slightly higher baud rates: F_CPU/28 and F_CPU/32, respectively. This is owing to subtle changes in the clock cycles for opcodes. So, yes, 9.6 MHZ/29 ~ 330 kbaud is the most you can hope to work here.
BTW, is there a good documentation for the timings of newer parts? Some of these have __AVR_XMEGA__ defined in the gcc-avr pre-processor: atmega1608 atmega1609 atmega3208 atmega3209 atmega4808 atmega4809 atmega808 atmega809 attiny1604 attiny1606 attiny1607 attiny1614 attiny1616 attiny1617 attiny202 attiny204 attiny212 attiny214 attiny3214 attiny3216 attiny3217 attiny402 attiny404 attiny406 attiny412 attiny414 attiny416 attiny417 attiny804 attiny806 attiny807 attiny814 attiny816 attiny817
Do these parts have XMEGA timings? @SpenceKonde @MCUdude @mcuee
mcuee
commented
1 year ago I am not an AVR expert but I read that they have a bit better timing than the xmega timing as mentioned in Chapter 4 of the following Microchip/Atmel document AVR® Instruction Set Manual. In the end, we can say the new AVRxt core (mega0, tiny0/1/2, avr DA/DB/DD) has better timing compated to AVRxm core (xmega).
In the manual, AVR DA is said to have the same AVRxm core as the xmega but I think it is a mistake, as the chip datasheet points to AVRxt core.
Examples, I can see improvement in instructions like SBIS, some cases of LD/LDD/ST/STD. https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-Instruction-Set-Manual-DS40002198A.pdf
mcuee
commented
1 year ago The Urboot for ATtiny13A seems to work fine.
It does not seem to be able to write to flash in terminal mode. EEPROM writing is okay.
mcuee
commented
1 year ago Same for normal mode. EEPROM writing is okay but not flash writing. Basically it does not write anything in the flash.
stefanrueger
commented
1 year ago @mcuee Thanks for testing! Looks like you need to enable SELFPRGEN in hfuse
avrdude> dump hfuse
0000 fb |. |@mcuee And thanks for the pointers to exact timings.
mcuee
commented
1 year ago @mcuee Thanks for testing! Looks like you need to enable
SELFPRGENinhfuseavrdude> dump hfuse 0000 fb |. |
That is it. Thanks for pointing out this apparent mistake. Now it works well.
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c usbasp -p t13a -qqt
avrdude> dump lfuse
0000 3a |: |
avrdude> dump hfuse
0000 eb |. |
avrdude> quit
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7 -p t13a -xshowall
avrdude_pr1309: AVR device initialized and ready to accept instructions
000020656854 0000-00-00 00.00 application 0 store 0 meta 0 boot 384 u7.7
weu-jpr-c vector 4 (EE_RDY) ATtiny13A
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7 -p t13a
-U .\zeros_t13a_test.hex
avrdude_pr1309: AVR device initialized and ready to accept instructions
avrdude_pr1309: device signature = 0x1e9007 (probably t13a)
avrdude_pr1309: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude_pr1309: erasing chip
avrdude_pr1309: reading input file .\zeros_t13a_test.hex for flash
with 256 bytes in 1 section within [0x100, 0x1ff]
using 8 pages and 0 pad bytes
avrdude_pr1309: preparing flash input for device bootloader
avrdude_pr1309: writing 256 bytes flash ...
Writing | ################################################## | 100% 0.04 s
avrdude_pr1309: 256 bytes of flash written
avrdude_pr1309: verifying flash memory against .\zeros_t13a_test.hex
Reading | ################################################## | 100% 0.04 s
avrdude_pr1309: 256 bytes of flash verified
avrdude_pr1309 done. Thank you.
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7 -p t13a -xshowall
avrdude_pr1309: AVR device initialized and ready to accept instructions
000020656854 2023-03-06 13.22 zeros_t13a_test.hex 512 store 97 meta 31 boot 384 u7.7
weu-jpr-c vector 4 (EE_RDY) ATtiny13A250,000 bps is also fine.
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c usbasp -p t13a -qq
-U .\urboot_attiny13a_9mhz6_250000bps_swio_rxb0_txb1_ee_lednop_fr_ce_ur_vbl.hex -qq && echo OK
OK
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7 -b 250000
-p t13a -xshowall
avrdude_pr1309: AVR device initialized and ready to accept instructions
000020656854 0000-00-00 00.00 application 0 store 0 meta 0 boot 384 u7.7
weu-jPr-c vector 4 (EE_RDY) ATtiny13A
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7 -b 250000
-p t13a -U .\zeros_t13a_test.hex
avrdude_pr1309: AVR device initialized and ready to accept instructions
avrdude_pr1309: device signature = 0x1e9007 (probably t13a)
avrdude_pr1309: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude_pr1309: erasing chip
avrdude_pr1309: reading input file .\zeros_t13a_test.hex for flash
with 256 bytes in 1 section within [0x100, 0x1ff]
using 8 pages and 0 pad bytes
avrdude_pr1309: preparing flash input for device bootloader
avrdude_pr1309: writing 256 bytes flash ...
Writing | ################################################## | 100% 0.04 s
avrdude_pr1309: 256 bytes of flash written
avrdude_pr1309: verifying flash memory against .\zeros_t13a_test.hex
Reading | ################################################## | 100% 0.02 s
avrdude_pr1309: 256 bytes of flash verified
avrdude_pr1309 done. Thank you.
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7 -b 250000
-p t13a -xshowall
avrdude_pr1309: AVR device initialized and ready to accept instructions
000020656854 2023-03-06 13.22 zeros_t13a_test.hex 512 store 97 meta 31 boot 384 u7.7
weu-jPr-c vector 4 (EE_RDY) ATtiny13A250,000 bps is also fine.
That's good. Thanks for testing @mcuee. Amazing that the bootloader works on such a small flash/sram. The smallest b/loader is 256 bytes so can be used for rapid prototyping...
mcuee
commented
1 year ago @MCUdude
Haha, now you may have a chance to add urboot to MicroCore. https://github.com/MCUdude/MicroCore
MCUdude
commented
1 year ago Adding Urboot to MicroCore is definitly something I'll consider!
The only problem is that when I designed the "MicroCore hardware", I decided to keep compatibility with the existing ATtinyCore and its bootloader implementation, so that ATtiny85's could be programmed usimmg my board without modifications.
The quirk here is that ATtinyCore and MicroCore use pin PB0 for TX, and PB1 for RX. The opposite of what the pre-compiled urboot binaries does.
mcuee
commented
1 year ago The quirk here is that ATtinyCore and MicroCore use pin PB0 for TX, and PB1 for RX. The opposite of what the pre-compiled urboot binaries does.
That should be a easy change.
MCUdude
commented
1 year ago It would be awesome to have a menu in the Arduino tools menu like this. For rapid prototyping, a bootloader is very convenient
Bootloader:
* No bootloader
* RX = PB1, TX = PB0
* RX = PB0, TX = PB1[TX/RX pin assignment] should be a easy change.
Sure. https://github.com/stefanrueger/urboot/blob/15ced5922bcc657b711eb3ba9a9f20fa92924a9a/src/mkurboots#L586-L608 can easily be changed. I've only set RX=PB0/TX=PB1 as default when nothing is known about typical boards that use this MCU. For some reason the t85 is down as RX=PB4/TX=PB3 presumably owing to the digispark board. You can add more configurations as a | separated list:
mcuio[attiny85]="SWIO=1 RX=AtmelPB1 TX=AtmelPB0|SWIO=1 RX=AtmelPB4 TX=AtmelPB3"I assume the microcore boards do not have a LED? That saves 6 bytes (choose a b/loader without _lednop and without _led[+-][a-f][0-7] in the name) . If desperate, I know two locations in urclock.c where two bytes each can be saved when needed: one lengthens the stop bits of sent bytes by 0.9 bits in SWIO (so download is marginally slower); the other is by removing wdr from setting the duration of the WDTO in watchdogConfig(). It's generally a mistake to skip wdr in the latter (because reducing the WDTO could trigger an immediate reset should the watchdog timer be progressed beyond the wanted WDTO), but I noticed optiboot does not use that wdr and that seems fine. I can only assume that a hardware reset also resets the internal WD timer to 0...
MCUdude
commented
1 year ago I'll look more into this tonight. The board has an onboard LED connected to pin PB2 (active high), but it would only make sense to add support for this if the compiled binary occupies 256 bytes or less.
stefanrueger
commented
1 year ago the compiled binary occupies 256 bytes or less
You can judge this by checking out if there is a _lednop bootloader that is within 256 bytes. This has "placeholder nops" for where LED twiddling goes once you know the pin. If there are only non-_lednop bootloaders within 256 bytes, then the bootloaders can be shortened by 4 bytes if needed through the tricks above. [edit: you need 6 bytes for LEDs]
| I can only assume that a hardware reset also resets the internal WD timer to 0...
That is actually highly likely come to think of that. Most AVR will have a fuse setting that switches on the WD timer by default. In order for these to work the WD timer needs to be reset to 0 on external (hard) reset. Otherwise there would be an unknown period for the first WDTO after external reset, which isn't acceptable. I believe the function that configures the WDTO in urboot is the only aspect where optiboot has shorter code (as optoboot drops the wdr)
MCUdude
commented
1 year ago It looks like the lednop bootloaders for ATtiny13/A are bigger than 256 bytes, so I think it's best with a bootloader that doesn't flash the LED while programming, but can instead fit within 256 bytes. https://github.com/stefanrueger/urboot.hex/tree/main/mcus/attiny13a/fcpu_9mhz6/115200_bps
(Ralph Doncaster actually created a 64-byte (!) sized bootloader, picoboot. I'm not sure how "safe" this is compared to Urboot, but it's still impressive in its own right!)
@stefanrueger could you add MicroCore as another "core" in the urboot repo that contains pre-compiled bootloaders for ATtiny13A with RXD=PB0/TXD=PB1 and RXD=PB1/TXD=PB0? I see no reason why not to add a bootloader option to MicroCore when a proper, failsafe bootloader can fit within 256 bytes!
MCUdude
commented
1 year ago I've just pushed a commit to the MicroCore repo where I've added Urboot as an option in the Arduino tools menu. Using Urboot with the 9.6 MHz internal oscillator works like a charm, but I'm having issues getting the 4.8MHz, 1.2MHz, and 600kHz options to work. @mcuee can you test it on your hardware? If you want to use Arduino IDE directly, you'll have to install MicroCore using the boards manager install, and then replace the installed core files with the one found in the repo on Github.
4.8 MHz option:
/Users/hans/Library/Arduino15/packages/MicroCore/tools/avrdude/7.1-arduino.1/bin/avrdude -C/Users/hans/Library/Arduino15/packages/MicroCore/hardware/avr/2.2.1/avrdude.conf -v -pattiny13a -curclock -b57600 -Uflash:w:/var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_151041/Blink.ino.hex:i
avrdude: Version 7.1-arduino.1
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/hans/Library/Arduino15/packages/MicroCore/hardware/avr/2.2.1/avrdude.conf
User configuration file is /Users/hans/.avrduderc
Using Port : /dev/cu.usbserial-1410
Using Programmer : urclock
Overriding Baud Rate : 57600
avrdude urclock_getsync() warning: attempt 1 of 10: not in sync
avrdude urclock_getsync() warning: attempt 2 of 10: not in sync
avrdude urclock_getsync() warning: attempt 3 of 10: not in sync
avrdude urclock_getsync() warning: attempt 4 of 10: not in sync
avrdude urclock_getsync() warning: attempt 5 of 10: not in sync
avrdude urclock_getsync() warning: attempt 6 of 10: not in sync
avrdude urclock_getsync() warning: attempt 7 of 10: not in sync
avrdude urclock_getsync() warning: attempt 8 of 10: not in sync
avrdude urclock_getsync() warning: attempt 9 of 10: not in sync
avrdude urclock_getsync() warning: attempt 10 of 10: not in sync
avrdude urclock_recv() warning: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude main() error: unable to open programmer urclock on port /dev/cu.usbserial-1410
avrdude done. Thank you.
the selected serial port
does not exist or your board is not connected1.2 MHz option:
/Users/hans/Library/Arduino15/packages/MicroCore/tools/avrdude/7.1-arduino.1/bin/avrdude -C/Users/hans/Library/Arduino15/packages/MicroCore/hardware/avr/2.2.1/avrdude.conf -v -pattiny13a -curclock -b19200 -Uflash:w:/var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_151041/Blink.ino.hex:i
avrdude: Version 7.1-arduino.1
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/hans/Library/Arduino15/packages/MicroCore/hardware/avr/2.2.1/avrdude.conf
User configuration file is /Users/hans/.avrduderc
Using Port : /dev/cu.usbserial-1410
Using Programmer : urclock
Overriding Baud Rate : 19200
AVR Part : ATtiny13A
Chip Erase delay : 4000 us
RESET disposition : dedicated
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 5 4 0 no 64 4 0 4000 4000 0xff 0xff
flash 65 6 32 0 yes 1024 32 32 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
calibration 0 0 0 0 no 2 1 0 0 0 0x00 0x00
Programmer Type : Urclock
Description : Urclock programmer for urboot bootloaders using urprotocol
Urboot protocol for ATtiny13A
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9007 (probably t13a)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude: erasing chip
delaying chip erase until first -U upload to flash
avrdude: reading input file /var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_151041/Blink.ino.hex for flash
with 78 bytes in 1 section within [0, 0x4d]
using 3 pages and 18 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 78 bytes flash ...
Writing | ################################################## | 100% 0.82s
avrdude: 78 bytes of flash written
avrdude: verifying flash memory against /var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_151041/Blink.ino.hex
Reading | #########################################An error occurred while uploading the sketch
######### | 100% 0.59s
avrdude avr_verify() warning: verification mismatch
device 0x13 != input 0x93 at addr 0x0020 (error)
device 0x80 != input 0xc0 at addr 0x0023 (error)
device 0x71 != input 0x31 at addr 0x0040 (error)
avrdude do_op() error: verification mismatch
avrdude done. Thank you600kHz option:
/Users/hans/Library/Arduino15/packages/MicroCore/tools/avrdude/7.1-arduino.1/bin/avrdude -C/Users/hans/Library/Arduino15/packages/MicroCore/hardware/avr/2.2.1/avrdude.conf -v -pattiny13a -curclock -b9600 -Uflash:w:/var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_151041/Blink.ino.hex:i
avrdude: Version 7.1-arduino.1
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/hans/Library/Arduino15/packages/MicroCore/hardware/avr/2.2.1/avrdude.conf
User configuration file is /Users/hans/.avrduderc
Using Port : /dev/cu.usbserial-1410
Using Programmer : urclock
Overriding Baud Rate : 9600
avrdude urclock_getsync() warning: attempt 1 of 10: not in sync
avrdude urclock_getsync() warning: attempt 2 of 10: not in sync
avrdude urclock_getsync() warning: attempt 3 of 10: not in sync
avrdude urclock_getsync() warning: attempt 4 of 10: not in sync
avrdude urclock_getsync() warning: attempt 5 of 10: not in sync
avrdude urclock_getsync() warning: attempt 6 of 10: not in sync
avrdude urclock_getsync() warning: attempt 7 of 10: not in sync
avrdude urclock_getsync() warning: attempt 8 of 10: not in sync
avrdude urclock_getsync() warning: attempt 9 of 10: not in sync
avrdude urclock_getsync() warning: attempt 10 of 10: not in sync
An error occurred while uploading the sketch
avrdude urclock_recv() warning: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude main() error: unable to open programmer urclock on port /dev/cu.usbserial-1410
avrdude done. Thank you.If 9m6 Hz @ 115200 baud works like a charm, then so should 4m8 Hz @ 57600 baud. It's even the same bootloader bit for bit, just that the entire "world" is slower. Will be the same for 1m2 Hz @ 14400 baud with exactly the same bootloader, no need to recompile or reflash. Could you try these fuse settings to effect the correct F_CPU and then set the correct -B <baud> for avrdude. Sometimes I find that certain -B ... settings are not done (haven't gone to the bottom of that) but there must be a way to verify avrdude is setting the baud rate correctly.
Ralph Doncaster actually created a 64-byte (!) sized bootloader
Yes, cool stuff. I read at the source and think I understand how it works. True, safety is all shifted to the uploader (but there is an eor check sum every 4 command bytes); there is no download; baud rate is a fixed function of F_CPU (no code left for delay loops to slow baud rate down), uploader needs to be able to create that baud rate, but yes, actually very cool stuff.
stefanrueger
commented
1 year ago I am unhappy with the alphabetic order of the oscillator frequency directories in the urboot.hex github so thought of
autobaud
b_F_cpu__24m_Hz
c_F_cpu__22m1184_Hz
d_F_cpu__20m_Hz
e_F_cpu__18m432_Hz
f_F_cpu__16m_Hz
g_F_cpu__14m7456_Hz
h_F_cpu__12m_Hz
i_F_cpu__11m0592_Hz
j_F_cpu___9m6_Hz
k_F_cpu___8m_Hz
l_F_cpu___7m3728_Hz
m_F_cpu___4m8_Hz
n_F_cpu___4m_Hz
o_F_cpu___3m6864_Hz
p_F_cpu___2m_Hz
q_F_cpu___1m8432_Hz
r_F_cpu___1m2_Hz
s_F_cpu___1m_Hz
t_F_cpu_600k_HzSimilarly for the baud rates
a_1000000_bps
b__500000_bps
c__460800_bps
d__250000_bps
e__230400_bps
f__125000_bps
g__115200_bps
h___76800_bps
i___57600_bps
j___38400_bps
k___28800_bps
l___19200_bps
m___14400_bps
n____9600_bps
o____7200_bps
p____4800_bps
q____3600_bps
r____2400_bps
s____1200_bpsDo I miss some?
stefanrueger
commented
1 year ago Could also do
autobaud
b_F_cpu_24.0000_MHz
c_F_cpu_22.1184_MHz
d_F_cpu_20.0000_MHz
e_F_cpu_18.4320_MHz
f_F_cpu_16.0000_MHz
g_F_cpu_14.7456_MHz
h_F_cpu_12.0000_MHz
i_F_cpu_11.0592_MHz
j_F_cpu__9.6000_MHz
k_F_cpu__8.0000_MHz
l_F_cpu__7.3728_MHz
m_F_cpu__4.8000_MHz
n_F_cpu__4.0000_MHz
o_F_cpu__3.6864_MHz
p_F_cpu__2.0000_MHz
q_F_cpu__1.8432_MHz
r_F_cpu__1.2000_MHz
s_F_cpu__1.0000_MHz
t_F_cpu__0.6000_MHzProbably even neater (thinking out loud here)
mcuee
commented
1 year ago If 9m6 Hz @ 115200 baud works like a charm, then so should 4m8 Hz @ 57600 baud. It's even the same bootloader bit for bit, just that the entire "world" is slower.
@MCUdude and @stefanrueger
Yes that is the case for me. I only need to change the fuse setting in this case.
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p t13a -qq
-U .\urboot_attiny13a_9mhz6_115200bps_swio_rxb0_txb1_ee_lednop_fr_ce_ur_vbl.hex && echo OK
OK
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7 -p t13a -xshowall
avrdude_pr1309: AVR device initialized and ready to accept instructions
000020656854 0000-00-00 00.00 application 0 store 0 meta 0 boot 384 u7.7
weu-jpr-c vector 4 (EE_RDY) ATtiny13A
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p t13a -qqt
avrdude> dump lfuse
0000 3a |: |
avrdude> write lfuse 0 0x39
avrdude> quit
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7
-b 57600 -p t13a -xshowall
avrdude_pr1309: AVR device initialized and ready to accept instructions
000020656854 0000-00-00 00.00 application 0 store 0 meta 0 boot 384 u7.7
weu-jpr-c vector 4 (EE_RDY) ATtiny13A
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7 -b 57600
-p t13a -U .\zeros_t13a_test.hex
avrdude_pr1309: AVR device initialized and ready to accept instructions
avrdude_pr1309: device signature = 0x1e9007 (probably t13a)
avrdude_pr1309: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude_pr1309: erasing chip
avrdude_pr1309: reading input file .\zeros_t13a_test.hex for flash
with 256 bytes in 1 section within [0x100, 0x1ff]
using 8 pages and 0 pad bytes
avrdude_pr1309: preparing flash input for device bootloader
avrdude_pr1309: writing 256 bytes flash ...
Writing | ################################################## | 100% 0.04 s
avrdude_pr1309: 256 bytes of flash written
avrdude_pr1309: verifying flash memory against .\zeros_t13a_test.hex
Reading | ################################################## | 100% 0.03 s
avrdude_pr1309: 256 bytes of flash verified
avrdude_pr1309 done. Thank you.
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7 -b 57600 -p t13a -xshowall
avrdude_pr1309: AVR device initialized and ready to accept instructions
000020656854 2023-03-06 13.22 zeros_t13a_test.hex 512 store 97 meta 31 boot 384 u7.7
weu-jpr-c vector 4 (EE_RDY) ATtiny13A
Same for 250000 bps firmware which will run at 125000bps for 4.8MHz clock.
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p t13a
-U .\urboot_attiny13a_9mhz6_250000bps_swio_rxb0_txb1_ee_lednop_fr_ce_ur_vbl.hex -qq && echo OK
OK
C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1309 -c urclock -P COM7 -b 125000 -p t13a
-U .\zeros_t13a_test.hex
avrdude_pr1309: AVR device initialized and ready to accept instructions
avrdude_pr1309: device signature = 0x1e9007 (probably t13a)
avrdude_pr1309: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude_pr1309: erasing chip
avrdude_pr1309: reading input file .\zeros_t13a_test.hex for flash
with 256 bytes in 1 section within [0x100, 0x1ff]
using 8 pages and 0 pad bytes
avrdude_pr1309: preparing flash input for device bootloader
avrdude_pr1309: writing 256 bytes flash ...
Writing | ################################################## | 100% 0.05 s
avrdude_pr1309: 256 bytes of flash written
avrdude_pr1309: verifying flash memory against .\zeros_t13a_test.hex
Reading | ################################################## | 100% 0.03 s
avrdude_pr1309: 256 bytes of flash verified
avrdude_pr1309 done. Thank you.
@MCUdude
I use your git master zip file to replace the MicroCore 2.2.1 release and change the avrdude version from 7.1-arduino.1 to avrdude PR 1309 (as I need to connect DTR pin directly to reset). I use 4.8MHz internal clock option to burn the bootloader.
MicroCore seems to have a problem that it does not pass the COM port number to avrdude. My breakout board has two LEDs on PB3 and PB4.
// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin LED_BUILTIN as an output.
pinMode(3, OUTPUT);
pinMode(4, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(3, HIGH); // turn the LED on (HIGH is the voltage level)
digitalWrite(4, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(3, LOW); // turn the LED off by making the voltage LOW
digitalWrite(4, LOW); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
}
C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\tools\avrdude\7.1-arduino.1/bin/avrdude -CC:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1/avrdude.conf -v -pattiny13a -cusbasp -B32 -e -Ulock:w:0xff:m -Uhfuse:w:0xeb:m -Ulfuse:w:0b00111001:m
avrdude: Version 7.1-20230106 (b1da0b09)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1\avrdude.conf
Using Port : usb
Using Programmer : usbasp
Setting bit clk period : 32.0
AVR Part : ATtiny13A
Chip Erase delay : 4000 us
RESET disposition : dedicated
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 5 4 0 no 64 4 0 4000 4000 0x00 0x00
flash 65 10 32 0 yes 1024 32 32 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
calibration 0 0 0 0 no 2 1 0 0 0 0x00 0x00
Programmer Type : usbasp
Description : USBasp, http://www.fischl.de/usbasp/
avrdude: set SCK frequency to 16000 Hz
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9007 (probably t13a)
avrdude: erasing chip
avrdude: set SCK frequency to 16000 Hz
avrdude: reading input file 0xff for lock
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lock ...
avrdude: 1 byte of lock written
avrdude: verifying lock memory against 0xff
avrdude: 1 byte of lock verified
avrdude: reading input file 0xeb for hfuse
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte hfuse ...
C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\tools\avrdude\7.1-arduino.1/bin/avrdude -CC:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1/avrdude.conf -v -pattiny13a -cusbasp -B32 -Uflash:w:C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1/bootloaders/urboot/fcpu_4mhz8/57600_bps/urboot_attiny13a_4mhz8_57600bps_swio_rxb0_txb1_ur_vbl.hex:i
avrdude: 1 byte of hfuse written
avrdude: verifying hfuse memory against 0xeb
avrdude: 1 byte of hfuse verified
avrdude: reading input file 0b00111001 for lfuse
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lfuse ...
avrdude: 1 byte of lfuse written
avrdude: verifying lfuse memory against 0b00111001
avrdude: 1 byte of lfuse verified
avrdude done. Thank you.
avrdude: Version 7.1-20230106 (b1da0b09)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1\avrdude.conf
Using Port : usb
Using Programmer : usbasp
Setting bit clk period : 32.0
AVR Part : ATtiny13A
Chip Erase delay : 4000 us
RESET disposition : dedicated
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 5 4 0 no 64 4 0 4000 4000 0x00 0x00
flash 65 10 32 0 yes 1024 32 32 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
calibration 0 0 0 0 no 2 1 0 0 0 0x00 0x00
Programmer Type : usbasp
Description : USBasp, http://www.fischl.de/usbasp/
avrdude: set SCK frequency to 16000 Hz
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9007 (probably t13a)
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: set SCK frequency to 16000 Hz
avrdude: reading input file C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1/bootloaders/urboot/fcpu_4mhz8/57600_bps/urboot_attiny13a_4mhz8_57600bps_swio_rxb0_txb1_ur_vbl.hex for flash
with 252 bytes in 2 sections within [0x300, 0x3ff]
using 8 pages and 4 pad bytes
avrdude: writing 252 bytes flash ...
Writing | ################################################## | 100% 0.12s
avrdude: 252 bytes of flash written
avrdude: verifying flash memory against C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1/bootloaders/urboot/fcpu_4mhz8/57600_bps/urboot_attiny13a_4mhz8_57600bps_swio_rxb0_txb1_ur_vbl.hex
Reading | ################################################## | 100% 0.00s
avrdude: 252 bytes of flash verified
avrdude done. Thank you.
C:\Program Files (x86)\Arduino\arduino-builder -dump-prefs -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\xfchen\AppData\Local\Arduino15\packages -hardware C:\Users\xfchen\Documents\Arduino\hardware -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\xfchen\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\xfchen\Documents\Arduino\libraries -fqbn=MicroCore:avr:13:clock=4M8,eeprom=keep,BOD=2v7,bootloader=rx_pb0_tx_pb1 -vid-pid=0403_6001 -ide-version=10819 -build-path C:\Users\xfchen\AppData\Local\Temp\arduino_build_841162 -warnings=all -build-cache C:\Users\xfchen\AppData\Local\Temp\arduino_cache_573347 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avr-gcc.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7 -prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino7.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7 -prefs=runtime.tools.avrdude.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\tools\avrdude\7.1-arduino.1 -prefs=runtime.tools.avrdude-7.1-arduino.1.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\tools\avrdude\7.1-arduino.1 -prefs=runtime.tools.arduinoOTA.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\arduino\tools\arduinoOTA\1.3.0 -prefs=runtime.tools.arduinoOTA-1.3.0.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\arduino\tools\arduinoOTA\1.3.0 -verbose C:\Users\xfchen\Documents\Arduino\Tiny13\Blink_t13\Blink_t13.ino
C:\Program Files (x86)\Arduino\arduino-builder -compile -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\xfchen\AppData\Local\Arduino15\packages -hardware C:\Users\xfchen\Documents\Arduino\hardware -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\xfchen\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\xfchen\Documents\Arduino\libraries -fqbn=MicroCore:avr:13:clock=4M8,eeprom=keep,BOD=2v7,bootloader=rx_pb0_tx_pb1 -vid-pid=0403_6001 -ide-version=10819 -build-path C:\Users\xfchen\AppData\Local\Temp\arduino_build_841162 -warnings=all -build-cache C:\Users\xfchen\AppData\Local\Temp\arduino_cache_573347 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avr-gcc.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7 -prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino7.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7 -prefs=runtime.tools.avrdude.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\tools\avrdude\7.1-arduino.1 -prefs=runtime.tools.avrdude-7.1-arduino.1.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\tools\avrdude\7.1-arduino.1 -prefs=runtime.tools.arduinoOTA.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\arduino\tools\arduinoOTA\1.3.0 -prefs=runtime.tools.arduinoOTA-1.3.0.path=C:\Users\xfchen\AppData\Local\Arduino15\packages\arduino\tools\arduinoOTA\1.3.0 -verbose C:\Users\xfchen\Documents\Arduino\Tiny13\Blink_t13\Blink_t13.ino
Using board '13' from platform in folder: C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1
Using core 'microcore' from platform in folder: C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1
Detecting libraries used...
"C:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-g++" -c -g -Os -flto -fno-reorder-blocks -ffixed-r2 -ffixed-r3 -ffixed-r4 -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -w -x c++ -E -CC -mmcu=attiny13a -DF_CPU=4800000L -DARDUINO=10819 -DARDUINO_attiny -DARDUINO_ARCH_AVR "-IC:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\MicroCore\\hardware\\avr\\2.2.1\\cores\\microcore" "-IC:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\MicroCore\\hardware\\avr\\2.2.1\\variants\\attiny13a" "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162\\sketch\\Blink_t13.ino.cpp" -o nul
Generating function prototypes...
"C:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-g++" -c -g -Os -flto -fno-reorder-blocks -ffixed-r2 -ffixed-r3 -ffixed-r4 -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -w -x c++ -E -CC -mmcu=attiny13a -DF_CPU=4800000L -DARDUINO=10819 -DARDUINO_attiny -DARDUINO_ARCH_AVR "-IC:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\MicroCore\\hardware\\avr\\2.2.1\\cores\\microcore" "-IC:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\MicroCore\\hardware\\avr\\2.2.1\\variants\\attiny13a" "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162\\sketch\\Blink_t13.ino.cpp" -o "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162\\preproc\\ctags_target_for_gcc_minus_e.cpp"
"C:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\builtin\\tools\\ctags\\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162\\preproc\\ctags_target_for_gcc_minus_e.cpp"
Compiling sketch...
"C:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-g++" -c -g -Os -flto -fno-reorder-blocks -ffixed-r2 -ffixed-r3 -ffixed-r4 -Wall -Wextra -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=attiny13a -DF_CPU=4800000L -DARDUINO=10819 -DARDUINO_attiny -DARDUINO_ARCH_AVR "-IC:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\MicroCore\\hardware\\avr\\2.2.1\\cores\\microcore" "-IC:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\MicroCore\\hardware\\avr\\2.2.1\\variants\\attiny13a" "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162\\sketch\\Blink_t13.ino.cpp" -o "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162\\sketch\\Blink_t13.ino.cpp.o"
Compiling libraries...
Compiling core...
Using precompiled core: C:\Users\xfchen\AppData\Local\Temp\arduino_cache_573347\core\core_ec45e0da1c16c0b0aa9e801fd974420c.a
Linking everything together...
"C:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-gcc" -Wall -Wextra -Os -flto -fno-reorder-blocks -ffixed-r2 -ffixed-r3 -ffixed-r4 -g -fuse-linker-plugin -Wl,--gc-sections -mrelax -mmcu=attiny13a -nostartfiles -Wl,--undefined=__vectors -o "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162/Blink_t13.ino.elf" "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162\\sketch\\Blink_t13.ino.cpp.o" "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162/..\\arduino_cache_573347\\core\\core_ec45e0da1c16c0b0aa9e801fd974420c.a" "-LC:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162" -lm
"C:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162/Blink_t13.ino.elf" "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162/Blink_t13.ino.eep"
"C:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-objcopy" -O ihex -R .eeprom "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162/Blink_t13.ino.elf" "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162/Blink_t13.ino.hex"
cmd /C echo. && "C:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-objdump" --disassemble --source --line-numbers --demangle --section=.text "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162/Blink_t13.ino.elf" > "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162/Blink_t13.ino_attiny13a_4800000L.lst"
"C:\\Users\\xfchen\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-size" -A "C:\\Users\\xfchen\\AppData\\Local\\Temp\\arduino_build_841162/Blink_t13.ino.elf"
Sketch uses 84 bytes (10%) of program storage space. Maximum is 768 bytes.
Global variables use 0 bytes (0%) of dynamic memory, leaving 64 bytes for local variables. Maximum is 64 bytes.
C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\tools\avrdude\7.1-arduino.1/bin/avrdude -CC:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1/avrdude.conf -v -pattiny13a -curclock -b57600 -Uflash:w:C:\Users\xfchen\AppData\Local\Temp\arduino_build_841162/Blink_t13.ino.hex:i
avrdude: Version 7.1-20230106 (b1da0b09)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1\avrdude.conf
Using Port : com1
Using Programmer : urclock
An error occurred while uploading the sketch
Overriding Baud Rate : 57600
avrdude ser_open() error: cannot open port \\.\com1: The system cannot find the file specified.
avrdude main() error: unable to open programmer urclock on port com1
avrdude done. Thank you.
Using command line and it works fine.
C:\work\avr\avrdude_test> C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\tools\avrdude\7.1-arduino.1/bin/avrdude -CC:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1/avrdude.conf -v -pattiny13a -curclock -PCOM7 -b57600 -Uflash:w:C:\Users\xfchen\AppData\Local\Temp\arduino_build_841162/Blink_t13.ino.hex:i
avrdude: Version 7.1-20230106 (b1da0b09)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1\avrdude.conf
Using Port : COM7
Using Programmer : urclock
Overriding Baud Rate : 57600
AVR Part : ATtiny13A
Chip Erase delay : 4000 us
RESET disposition : dedicated
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 5 4 0 no 64 4 0 4000 4000 0x00 0x00
flash 65 10 32 0 yes 1024 32 32 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
calibration 0 0 0 0 no 2 1 0 0 0 0x00 0x00
Programmer Type : Urclock
Description : Urclock programmer for urboot bootloaders using urprotocol
Urboot protocol for ATtiny13A
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9007 (probably t13a)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude: erasing chip
delaying chip erase until first -U upload to flash
avrdude: reading input file C:\Users\xfchen\AppData\Local\Temp\arduino_build_841162/Blink_t13.ino.hex for flash
with 84 bytes in 1 section within [0, 0x53]
using 3 pages and 12 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 84 bytes flash ...
Writing | ################################################## | 100% 0.50 s
avrdude: 84 bytes of flash written
avrdude: verifying flash memory against C:\Users\xfchen\AppData\Local\Temp\arduino_build_841162/Blink_t13.ino.hex
Reading | ################################################## | 100% 0.29 s
avrdude: 84 bytes of flash verified
avrdude done. Thank you.BTW, no issues with 9.6MHz 115200bps as well using the command line workaround.
mcuee
commented
1 year ago 1.2MHz works fine as well (19200bps).
C:\work\avr\avrdude_test> C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\tools\avrdude\7.1-arduino.1/bin/avrdude -CC:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1/avrdude.conf -v -pattiny13a -curclock -PCOM7 -b19200 -Uflash:w:C:\Users\xfchen\AppData\Local\Temp\arduino_build_841162/Blink_t13.ino.hex:i
avrdude: Version 7.1-20230106 (b1da0b09)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1\avrdude.conf
Using Port : COM7
Using Programmer : urclock
Overriding Baud Rate : 19200
AVR Part : ATtiny13A
Chip Erase delay : 4000 us
RESET disposition : dedicated
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 5 4 0 no 64 4 0 4000 4000 0x00 0x00
flash 65 10 32 0 yes 1024 32 32 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
calibration 0 0 0 0 no 2 1 0 0 0 0x00 0x00
Programmer Type : Urclock
Description : Urclock programmer for urboot bootloaders using urprotocol
Urboot protocol for ATtiny13A
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9007 (probably t13a)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude: erasing chip
delaying chip erase until first -U upload to flash
avrdude: reading input file C:\Users\xfchen\AppData\Local\Temp\arduino_build_841162/Blink_t13.ino.hex for flash
with 84 bytes in 1 section within [0, 0x53]
using 3 pages and 12 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 84 bytes flash ...
Writing | ################################################## | 100% 0.85 s
avrdude: 84 bytes of flash written
avrdude: verifying flash memory against C:\Users\xfchen\AppData\Local\Temp\arduino_build_841162/Blink_t13.ino.hex
Reading | ################################################## | 100% 0.64 s
avrdude: 84 bytes of flash verified
avrdude done. Thank you.
I am not able to get 600KHz internal clock to work (9600bps).
C:\work\avr\avrdude_test> C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\tools\avrdude\7.1-arduino.1/bin/avrdude -CC:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1/avrdude.conf -v -pattiny13a -curclock -PCOM7 -b9600 -Uflash:w:C:\Users\xfchen\AppData\Local\Temp\arduino_build_841162/Blink_t13.ino.hex:i -B3
avrdude: Version 7.1-20230106 (b1da0b09)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1\avrdude.conf
Using Port : COM7
Using Programmer : urclock
Overriding Baud Rate : 9600
Setting bit clk period : 3.0
avrdude urclock_getsync() warning: attempt 1 of 10: not in sync
avrdude urclock_getsync() warning: attempt 2 of 10: not in sync
avrdude urclock_getsync() warning: attempt 3 of 10: not in sync
avrdude urclock_getsync() warning: attempt 4 of 10: not in sync
avrdude urclock_getsync() warning: attempt 5 of 10: not in sync
avrdude urclock_getsync() warning: attempt 6 of 10: not in sync
avrdude urclock_getsync() warning: attempt 7 of 10: not in sync
avrdude urclock_getsync() warning: attempt 8 of 10: not in sync
avrdude urclock_getsync() warning: attempt 9 of 10: not in sync
avrdude urclock_getsync() warning: attempt 10 of 10: not in sync
avrdude urclock_recv() warning: programmer is not responding; try -xstrict and/or vary -xdelay=100
avrdude main() error: unable to open programmer urclock on port COM7
avrdude done. Thank you.
If 9m6 Hz @ 115200 baud works like a charm, then so should 4m8 Hz @ 57600 baud. It's even the same bootloader bit for bit, just that the entire "world" is slower. Will be the same for 1m2 Hz @ 14400 baud with exactly the same bootloader, no need to recompile or reflash.
When running the MicroCore oscillator calibration sketch, it appears that the internal 4.8 MHz and the 9.6 MHz needs different OSCCAL values in order to be on point. The 4.8MHz one is more "off" than the 9.6 MHz one, but both of them need their OSCCAL value increased with about 5-8 steps. This is definitely why I'm having these issues.
I'm not sure it's possible to within the 256-byte mark, but it would be awesome if the bootloader could read EEPROM address 0 and load the value into the OSCCAL register if the value was appropriate. This way, the users could run the oscillator calibration sketch first, and then flash the bootloader. However, it would even be better if the OSCCAL value in EEPROM could be "burned" into the flash memory when the bootloader is flashed. Not sure how this could be accomplished. But the ATtiny13s are known for their inaccurate internal oscillators. I actually had an ATTiny13 I bought from Aliexpress where the 9.6MHz oscillator was actually running at 9 MHz. Pretty much useless for timing-critical applications unless the correct value was loaded into its OSCCAL register on boot.
From the ATtiny13 datasheet:
The signature area of the ATtiny13 contains two bytes of calibration data for the internal oscillator. The calibration data in the high byte of address 0x00 is for use with the oscillator set to 9.6 MHz operation. During reset, this byte is automatically written into the OSCCAL register to ensure correct frequency of the oscillator. There is a separate calibration byte for the internal oscillator in 4.8 MHz mode of operation but this data is not loaded automatically. The hardware always loads the 9.6 MHz calibraiton data during reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCAL register must be updated by firmware. The calibration data for 4.8 MHz operation is located in the high byte at address 0x01 of the signature area.
MCUdude
commented
1 year ago I am unhappy with the alphabetic order of the oscillator frequency directories in the urboot.hex github
Have a look at how I'll have to deal with the bootloader binary file names: https://github.com/MCUdude/MicroCore/blob/master/avr/boards.txt
At least for me and my Arduino cores, it's important that the names are consistent and easy to handle with the limits the boards.txt parser has.
I'm not a huge fan of the [a-z] prefix because this would be difficult to deal with. It also means that existing hex files need to be renamed if/when new bootloaders are added to the directory.
I do agree that alphabetic order is very neat, as long as the boards.txt parser is able to handle the file names without too many workarounds
mcuee
commented
1 year ago MicroCore seems to have a problem that it does not pass the COM port number to avrdude. My breakout board has two LEDs on PB3 and PB4.
Thanks for reporting! I've been using a
.avrdudercfile where a default serial port is specified, so I didn't notice this issue. I've just pushed a fix for this.
Yes, the latest git is good.
mcuee
commented
1 year ago When running the MicroCore oscillator calibration sketch, it appears that the internal 4.8 MHz and the 9.6 MHz needs different OSCCAL values in order to be on point. The 4.8MHz one is more "off" than the 9.6 MHz one, but both of them need their OSCCAL value increased with about 5-8 steps. This is definitely why I'm having these issues.
Yes. It is also mentioned in the datasheet Section 6.2.2 Calibrated Internal 4.8/9.6 MHz Oscillator and Section 173.
17.3 Calibration Bytes The signature area of the ATtiny13A contains two bytes of calibration data for the internal oscillator. The calibration data in the high byte of address 0x00 is for use with the oscillator set to 9.6 MHz operation. During reset, this byte is automatically written into the OSCCAL register to ensure correct frequency of the oscillator.
There is a separate calibration byte for the internal oscillator in 4.8 MHz mode of operation but this data is not loaded automatically. The hardware always loads the 9.6 MHz calibration data during reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCAL register must be updated by firmware. The calibration data for 4.8 MHz operation is located in the high byte at address 0x01 of the signature area.
I'm not sure it's possible to within the 256-byte mark, but it would be awesome if the bootloader could read EEPROM address 0 and load the value into the OSCCAL register if the value was appropriate. This way, the users could run the oscillator calibration sketch first, and then flash the bootloader. However, it would even be better if the OSCCAL value in EEPROM could be "burned" into the flash memory when the bootloader is flashed. Not sure how this could be accomplished. But the ATtiny13s are known for their inaccurate internal oscillators. I actually had an ATTiny13 I bought from Aliexpress where the 9.6MHz oscillator was actually running at 9 MHz. Pretty much useless for timing-critical applications unless the correct value was loaded into its OSCCAL register on boot.
Good idea.
mcuee
commented
1 year ago @MCUdude
Another potential improvement for the MicroCore, As there is no urboot hex file for 128KHz internal oscillator, it is good to mention that in the menu. I am not so sure if that is easy to fix or not.
avrdude ioerror() OS error: file C:\Users\xfchen\AppData\Local\Arduino15\packages\MicroCore\hardware\avr\2.2.1/bootloaders/urboot/fcpu_{bootloader.speed}/{bootloader.baudrate}_bps/urboot_attiny13a_{bootloader.speed}_{bootloader.baudrate}bps_swio_rxb0_txb1_ur_vbl.hex is not readable: No such file or directory| would be awesome if the bootloader could read EEPROM address 0 and load the value into the OSCCAL register
Would it not make sense for the calibration script to store the OSCAL value? If the bootloader does that it renders EEPROM location 0 unusable for all applications and increases its size.
MCUdude
commented
1 year ago I also wrote
However, it would even be better if the OSCCAL value in EEPROM could be "burned" into the flash memory when the bootloader is flashed.
Perhaps an approach like this makes more sense.
Just an idea:
Another idea:
stefanrueger
commented
1 year ago How about the calibration script tells the user an estimate of the effective F_CPU. We could provide bootloaders for F_CPU +/- 1.5% and +/- 3%. That gives 5 different bootloaders to choose from. The baud rate can be some 2% off, so we cater for F_CPU errors of +/- 5% for internal oscillators. When burning the bootloader the user can choose the closest bootloader for the effective F_CPU with the knowledge of the output of the calibration script.
stefanrueger
commented
1 year ago Avrdude reads the EEPROM value (and perhaps a flag as an indicator that there's a valid OSCCAL value and not random, leftover data) and puts this straight into flash at a specific address so that the bootloader always loads this exact value into the OSCCAL register
That is the idea of template bootloaders: modify LED, WDTO, CS line for dual boot in the bootloader .hex file at burn time. (Could be extended to OSCAL). Avrdude has no (dedicated) support for bootloader burning but I am using a sketch on a ProMini to burn template bootloaders (not Avrdude)
stefanrueger
commented
1 year ago From the Attiny13a data sheet: To ensure stable operation of the MCU the calibration value should be changed in small steps. A variation in frequency of more than 2% from one cycle to the next can lead to unpredicatble behavior. Changes in OSCCAL should not exceed 0x20 for each calibration.
Is that a thing in reality? It would be quite some algorithm to having to read the reset-time factory calibration value, then compare to the destination OSCCAL and then increment/decrement its value until it matches the desired OSCCAL is reached. Do people do this or do they (brutally!) overwrite the OSCCAL register with any old value?
The more I think about it, the more I lean towards preparing bootloaders for several F_CPU spaced 1.5% or 2% apart.
MCUdude
commented
1 year ago To ensure stable operation of the MCU the calibration value should be changed in small steps. A variation in frequency of more than 2% from one cycle to the next can lead to unpredicatble behavior. Changes in OSCCAL should not exceed 0x20 for each calibration. Is that a thing in reality?
I highly doubt this, but in reality, the oscillator is usually only a few percent off anyways, so the "jump" isn't that big in reality.
The more I think about it, the more I lean towards preparing bootloaders for several F_CPU spaced 1.5% or 2% apart.
This is a good idea, but IMO it's only needed for the ATtiny13, and for the 9.6 MHz and 1,2 MHz ("oscillator 1"), 4.8 MHz, and 600kHz ("oscillator 2"). And in all cases I've seen the oscillator has always been too slow, and never too fast.
I'll probably provide a bootloader menu option like this with MicroCore:
- Bootloader
- No
- Yes (RX = PB1, TX = PB0, 0%)
- Yes (RX = PB1, TX = PB0, -1.5%)
- Yes (RX = PB1, TX = PB0, -3%)
- Yes (RX = PB1, TX = PB0, -4.5%)
- Yes (RX = PB1, TX = PB0, -6%)
- Yes (RX = PB0, TX = PB1, 0%)
- Yes (RX = PB0, TX = PB1, -1.5%)
- Yes (RX = PB0, TX = PB1, -3%)
- Yes (RX = PB0, TX = PB1, -4.5%)
- Yes (RX = PB0, TX = PB1, -6%)The other parts have internal oscillators, too, not? Normally at 8 MHz, so would make sense to provide a series of nearby frequencies for 8 MHz and 1 MHz for parts different from t13 and t13a. Also, most (all?) parts can be set to run on 128 kHz. We could create pre-compiled bootloaders for these frequencies, too.
We might only need to create these extra frequencies for parts without a UART. If the part has UART, one can always use an autobaud bootloader and use a really low baudrate in relation to fcpu. fcpu/260 should work for sure. Higher baud rates may be in a region that is incompatible with fcpu, see these example intervals. Note I got the 260 from that discussion as 8*33/1.015.
BTW, there is a subtle challenge in stepping Fcpu up and down in intervals: The quantisation of high UART baud rates (relative to fcpu) for classic parts can be severely off in certain fcpu/br regions as seen above. Even if the UART (just about) works, eg, 8 MHz and 57,600 baud, the generated baud rate is +2.12% too high. This means that if I were to step down F_CPU by 1.5% I would still get the same BRR divisor (and therefore the same bootloader bit for bit) just that the nominal baud rate quantisation error drops to ~ +0.6%. Soooooooo, I am thinking to use SWIO when the UART baud rate quantisation error exceeds 0.75% and also not create SWIO bootloaders that exceed 0.75% quantisation error. Fun fact: for baud rates below fcpu/66.7 (and above some limit) my SWIO routines are guaranteed to be within 0.75% quantisation error: fcpu/br is the number of cycles per transmitted bit; here this is 66.7. The error in my SWIO routines is never more than 0.5 cycles, so max quantisation error is 0.5/66.7 = 0.75%. I believe optiboot has a 4.5% worst-case quantisation for baud rates in the vincinity of fcpu/66.7 because the code is based on the (for this suboptimal) Atmel AN 305 that allows the number of cycles per bit to be off by max 3.
TLDR; hopefully my strategy will create bootloaders that are different for slightly different fcpu and that they cover the mis-tuned internal oscillators.
stefanrueger
commented
1 year ago Just wondering why you plan to offer both RX = PB1, TX = PB0 and RX = PB0, TX = PB1? I thought your microcore had only the former pin assignment?
MCUdude
commented
1 year ago The other parts have internal oscillators, too, not?
Yes, they do, but I'm my experience, these are for some reason not as "off" as the one(s) found in the ATtiny13.
We might only need to create these extra frequencies for parts without a UART.
That would make the most sense IMO. I'll only bundle Urboot autobaud bootloaders to my cores anyways, so a fine-tuned F_CPU value is in my case only needed with MicroCore/ATtiny13. But I understand that you target audiences other than just users of my Arduino cores.
Just wondering why you plan to offer both RX = PB1, TX = PB0 and RX = PB0, TX = PB1? I thought your microcore had only the former pin assignment?
My plan is to offer both if the bootloader menu In Arduino IDE doesn't get too cluttered.
stefanrueger
commented
1 year ago fine-tuned F_CPU value is in my case only needed with MicroCore/ATtiny13
Understood. Will do, but like to do things in a general way (so they benefit a wider audience).
Will have a slightly different naming scheme in the next iteration for publishing pre-compiled bootloaders, so that browsing the tree is easier for a human.. Needed to deploy + instead of _ so github sorts the directories in numerically consistent way. Could have used leading 0 but that turned out to look ugly and confusing.
I am thinking of having fcpu++8m0000_Hz directory names for external oscillators (quartzes with 20 ppm and resonators with 2000 ppm accuracy, eg). These are good enough so that we can afford quantisation errors through the UART with up to 2.1% error. High baudrates are likely to work.
In contrast to this I propose to have fint++8m0000_Hz directory names for internal oscillators which are notoriously imprecise and which can exceed 2% deviation errors. For these I will limit generated bootloaders to small(ish) baud rates, say fcpu/67 and smaller for which I can generate baud rates with a small quantisation error and a few +/- percent varying fcpu.
While I write this, maybe, to be ultra-clear, I should name the directories for external oscillators fext+..._hz not fcpu+..._hz.
Also making urprotocol=1 the default in file names, so the exception is _stk500 and its absence means what used to be _ur. Hardware supported bootloaders will have _hw added and its absence means vector boot loader (what used to be indicated with _vbl). Am hoping that this settles in before I tag the urboot and urboot.hex projects with their "official" first release as v7.7.
stefanrueger
commented
1 year ago OK, done. See how you like the new pre-compiled bootloaders in urboot.hex, @MCUdude
Could you especially try the bootloaders for internal oscillators. They are meant to exhibit a low baud rate quantisation error. This and that there are a few ones for Fcpu variations should get the difficult 4.8 MHz b/loader going.
stefanrueger
commented
1 year ago As there is no urboot hex file for 128KHz internal oscillator, it is good to mention that in the menu.
There are now @mcuee
MCUdude
commented
1 year ago Thanks, @stefanrueger! I'll run some tests later this evening and update the bootloader binaries I've bundled with MicroCore.
IMO the new naming convention is a bit odd IMO. I do understand that all the pluses are there for padding reasons, but or look a bit cryptic to the naked eye.
mcus/attiny13a/internal_oscillator/fint++0m133120_Hz/br++++0k3_bps/urboot+attiny13a++0m133120i++++0k3_swio_rxb0_txb1_led+b2.hexnew naming convention
Yes, I needed to get used to that, too.
I tried underscores (sorts wrong), dashes (sorts wrong), dots (looks odd with proportional font), leading zeros (also looks odd, particularly baud rates are hard to read as they span 4 orders). Haven't tried spaces (they are a pain for shell scripts but apparently they sort wrong too) and haven't tried colons (these would be funny, particularly for windows :wink:) Any suggestions? Now is a good time to get this right.
Somehow Unix ls is remarkable in that ordinary ASCII sort is too much to ask. Github also doesn't give you much control over order.
Do you have a suggestion that makes github display these files in the "right" order?
Unlike other AVRs, the internal oscillator in the ATtiny13/A runs at 9.6 MHz and is dividable down to 4.8 MHz, 1.2MHz, and 600kHz. It would be great if these existed pre-compiled bootloaders for these clock speeds!