Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not work reliably on MacOSX/Mx processors #25

Open
jhusak opened this issue Jan 5, 2025 · 6 comments
Open

Does not work reliably on MacOSX/Mx processors #25

jhusak opened this issue Jan 5, 2025 · 6 comments

Comments

@jhusak
Copy link

jhusak commented Jan 5, 2025

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
@baerwolf
Copy link
Owner

baerwolf commented Jan 6, 2025 via email

@jhusak
Copy link
Author

jhusak commented Jan 7, 2025

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).

@jhusak
Copy link
Author

jhusak commented Jan 7, 2025

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.

@baerwolf
Copy link
Owner

baerwolf commented Jan 7, 2025 via email

@jhusak
Copy link
Author

jhusak commented Jan 8, 2025

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.

@jhusak
Copy link
Author

jhusak commented Jan 8, 2025

Yes, that AVR mega168pb works without a hassle on other mac intel, MacOS X Mojave, never experienced any troubles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants