baerwolf
Does not work reliably on MacOSX/Mx processors
On Macs M1/Mx during flashing with avrdude hangs at random positions if compiled with -DCONFIG_USE__EXCESSIVE_ASSEMBLER (on MacOs Intel with avrdude works perfectly). Compiled to pure C code hangs very occasionally (once per several flashings)
log:
avrdude: Version 7.2
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /opt/homebrew/etc/avrdude.conf
User configuration file is /Users/qba/.avrduderc
User configuration file does not exist or is not a regular file, skipping
Using Port : usb
Using Programmer : usbasp
Setting bit clk period : 250.0
avrdude: input file main.hex auto detected as Intel Hex
AVR Part : ATmega168PB
Chip Erase delay : 10500 us
PAGEL : PD7
BS2 : PC2
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 20 4 0 no 512 4 0 3600 3600 0x00 0x00
flash 65 10 128 0 yes 16384 128 128 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
efuse 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 1 1 0 0 0 0x00 0x00
Programmer Type : usbasp
Description : USBasp ISP and TPI programmer
avrdude: set SCK frequency to 4000 Hz
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9415 (probably m168pb)
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 4000 Hz
avrdude: processing -U flash:w:main.hex:i
avrdude: reading input file main.hex for flash
with 8567 bytes in 2 sections within [0, 0x37ff]
using 68 pages and 137 pad bytes
avrdude: writing 8567 bytes flash ...
Writing | ############-------------------------------------- | 23% 0.85 s
avrdude usbasp_transmit() OS error: Input/output error
avrdude usbasp_spi_paged_write() error: wrong count at writing ffffffff
^Cmake: *** [upload] Interrupt: 2
Hi
Thank you for your report.
Does this also happen when using an usb 2.0 HUB?
(With transaction translation from 1.5Mbps USB 1 to 480Mbps USB 2)
Can you also test older AVR like PA models (atmega168pa)? Do they behave similarly?)
BR
Stephan B. ***@***.***> hat am 06.01.2025 20:20 CET geschrieben:
-------- Forwarded Message --------
Subject:
[baerwolf/USBaspLoader] Does not work reliably on MacOSX/Mx processors (Issue #25)
Date:
Sun, 05 Jan 2025 05:26:57 -0800
From:
jhusak ***@***.***>
Reply-To:
baerwolf/USBaspLoader ***@***.***>
To:
baerwolf/USBaspLoader ***@***.***>
CC:
Subscribed ***@***.***>
On Macs M1/Mx during flashing with avrdude hangs at random positions if compiled with EXTENSIVE_ASSEMBLER (on MacOs Intel with avrdude works perfectly).Compiled to pure C code hangs very occasionally (once per several flashings)
log:`avrdude: Version 7.2Copyright the AVRDUDE authors;see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /opt/homebrew/etc/avrdude.conf
User configuration file is /Users/qba/.avrduderc
User configuration file does not exist or is not a regular file, skipping
Using Port : usb
Using Programmer : usbasp
Setting bit clk period : 250.0
avrdude: input file main.hex auto detected as Intel HexAVR Part : ATmega168PBChip Erase delay : 10500 usPAGEL : PD7BS2 : PC2RESET disposition : possible i/oRETRY pulse : SCKSerial program mode : yesParallel program mode : yesTimeout : 200StabDelay : 100CmdexeDelay : 25SyncLoops : 32PollIndex : 3PollValue : 0x53Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 512 4 0 3600 3600 0x00 0x00
flash 65 10 128 0 yes 16384 128 128 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
efuse 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 1 1 0 0 0 0x00 0x00
Programmer Type : usbasp
Description : USBasp ISP and TPI programmer
avrdude: set SCK frequency to 4000 Hzavrdude: AVR device initialized and ready to accept instructionsavrdude: device signature = 0x1e9415 (probably m168pb)avrdude: Note: flash memory has been specified, an erase cycle will be performed.To disable this feature, specify the -D option.avrdude: erasing chipavrdude: set SCK frequency to 4000 Hz
avrdude: processing -U flash:w:main.hex:iavrdude: reading input file main.hex for flashwith 8567 bytes in 2 sections within [0, 0x37ff]using 68 pages and 137 pad bytesavrdude: writing 8567 bytes flash ...Writing | ############-------------------------------------- | 23% 0.85 savrdude usbasp_transmit() OS error: Input/output erroravrdude usbasp_spi_paged_write() error: wrong count at writing ffffffff
^Cmake: *** [upload] Interrupt: 2`
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
Yes, also Atmega8A behaves identically. Generally there are transmition errors sometimes as the uc gets programmed wrongly even if everything went ok without verification. With verification I have to test again because things to not add up in my brain.
Also, at the end, the new "atmegaxxxpb" microcontrollers can be added as handled as they work perfectly (on not Mx computers).
Example of verify error when programming went "ok" ie without hangups.
avrdude: verifying flash memory against main.hex
Reading | ################################################## | 100% 1.36 s
avrdude avr_verify() warning: verification mismatch
device 0x00 != input 0x0c at addr 0x0000 (error)
device 0x80 != input 0x94 at addr 0x0001 (error)
device 0x08 != input 0x0c at addr 0x0004 (error)
device 0x00 != input 0x94 at addr 0x0005 (error)
device 0x04 != input 0x94 at addr 0x0009 (error)
device 0x90 != input 0xb1 at addr 0x000a (error)
device 0x00 != input 0x0c at addr 0x000c (error)
device 0x90 != input 0x94 at addr 0x000d (error)
device 0x90 != input 0xb1 at addr 0x000e (error)
avrdude do_op() error: verification mismatch
avrdude done. Thank you.
Okay noted
Does the same AVR device work proper on an other non-Mx device ?
If not it could be non-isb issue like fuses.
Another thing to test would be (as previously noted) using usb 2.0 hub. Perhaps usb 1.0 is fishy in apple Mx. Combined with avr-usb being non-compliant usb hack it could be cause for trouble. Using usb 2.0 hub should talk to Apple Mx in a more compliant way.
BR
P.s :
Which clockspeed are you using?
Stephan B. ***@***.***> hat am 07.01.2025 22:24 CET geschrieben:
-------- Forwarded Message --------
Subject:
Re: [baerwolf/USBaspLoader] Does not work reliably on MacOSX/Mx processors (Issue #25)
Date:
Tue, 07 Jan 2025 08:36:27 -0800
From:
jhusak ***@***.***>
Reply-To:
baerwolf/USBaspLoader ***@***.***>
To:
baerwolf/USBaspLoader ***@***.***>
CC:
Stephan Baerwolf ***@***.***>, Comment ***@***.***>
Example of verify error when programming went "ok" ie without hangups.
avrdude: verifying flash memory against main.hex
Reading | ################################################## | 100% 1.36 s avrdude avr_verify() warning: verification mismatch device 0x00 != input 0x0c at addr 0x0000 (error) device 0x80 != input 0x94 at addr 0x0001 (error) device 0x08 != input 0x0c at addr 0x0004 (error) device 0x00 != input 0x94 at addr 0x0005 (error) device 0x04 != input 0x94 at addr 0x0009 (error) device 0x90 != input 0xb1 at addr 0x000a (error) device 0x00 != input 0x0c at addr 0x000c (error) device 0x90 != input 0x94 at addr 0x000d (error) device 0x90 != input 0xb1 at addr 0x000e (error) avrdude do_op() error: verification mismatch
avrdude done. Thank you.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
It looks that connected through USB3.0 hub UNITEK Y-3089 (no 2.0) works almost well both with -DCONFIG_USE__EXCESSIVE_ASSEMBLER or not. I use 12Mhz.
Almost because once every several tries:
avrdude: set SCK frequency to 750000 Hz
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9415 (probably m168pb)
avrdude: erasing chip
avrdude: set SCK frequency to 750000 Hz
avrdude: processing -U flash:w:main.hex:i
avrdude: reading input file main.hex for flash
with 8641 bytes in 2 sections within [0, 0x37ff]
using 69 pages and 191 pad bytes
avrdude: writing 8641 bytes flash ...
Writing | ################################################## | 100% 0.90 s
avrdude: 8641 bytes of flash written
avrdude: verifying flash memory against main.hex
Reading | #################--------------------------------- | 33% 0.30 s
avrdude usbasp_transmit() OS error: Input/output error
avrdude usbasp_transmit() OS error: Input/output error
avrdude usbasp_spi_paged_load() error: wrong reading bytes ffffffff
avrdude usbasp_transmit() OS error: Input/output error
avrdude usbasp_spi_cmd() error: wrong response size
avrdude avr_read_mem() error: unable to read byte at address 0x0000
avrdude avr_read_mem() error: read operation not supported for memory flash
avrdude do_op() error: unable to read all of flash memory, rc=-2
avrdude usbasp_transmit() OS error: Unknown libusb error code -99
make: *** [upload] Segmentation fault: 11
However, I remain, that if USBaspLoader is compiled -DCONFIG_USE__EXCESSIVE_ASSEMBLER it is almost impossible to flash a firmware through it (when direct connected to mac Mx USB), and without this option the bug very occasionally happens (with hub) or occasionally (without it). So maybe problem with Mx is that bug occasionally happens, and there is some on-the-edge time constraints exceeded when asm is used. My assumptions.
Yes, that AVR mega168pb works without a hassle on other mac intel, MacOS X Mojave, never experienced any troubles.