Mac Pro, OS 10.15 Catalina, AVRDUDE problems

[dlv]

Hello Everyone.

First post. I've done a fair amount of Arduino programming in past years on multiple Mac computers (MacBook Pro and mini). However I recently purchased a Mac Pro and can't get avrdude to upload a sketch.

I have an Uno R3. Older board, not a clone. My MacBook Pro was running Yosemite. I no longer have it. Everything works fine on my current Mac mini running Mojave. I can compile and upload blink to the Uno. So I know I have a working Uno board and USB cable.

On my Mac Pro (2010 5,1) running Catalina (10.15.6) I can compile but the upload fails with AVRDude errors. I suspect it's something to do with Catalina, or possibly the Mac Pro, but I cannot figure it out.

Arduino: 1.8.19 (Mac OS X), Board: "Arduino Uno"

Sketch uses 924 bytes (2%) of program storage space. Maximum is 32256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.
/Users/dveach/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/bin/avrdude -C/Users/dveach/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/etc/avrdude.conf -v -patmega328p -carduino -P/dev/cu.usbmodem5D101 -b115200 -D -Uflash:w:/var/folders/gb/nb_350cn6w9d7jkqlpw0d93w0000gn/T/arduino_build_929559/Blink.ino.hex:i 

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/Users/dveach/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/etc/avrdude.conf"
         User configuration file is "/Users/dveach/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodem5D101
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done.  Thank you.

Problem uploading to board.  See https://support.arduino.cc/hc/en-us/sections/360003198300 for suggestions.


This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Board selected is Uno.

Programmer selected is ArduinoISP but I've read that doesn't matter when uploading a sketch? I tried different selections and it didn't fix the issue.

I'm using the right port and that port seems to recognize the Uno just fine.

I can get board info and I've tried a serial loopback test and that works too. So serial comm is working.

The Mac Pro is a 4,1 that was flashed to a 5,1. Not sure if that could have anything to do with it.

I saw some forum posts about the IDE needing Xcode on Catalina so I installed Xcode. That did not make any difference.

I've seen posts from 2020 and 2021 about Catalina issues but none of them really gave me any clues. They seemed to be more about driver problems in earlier Catalina releases.

I'm stumped if this could be a hardware issue (Mac Pro 4,1 USB ports? I did notice that my Mac mini is USB 3.0 while the Mac Pro is USB 2.0. I doubt that's it since serial communication is confirmed.

I really do not know what to try next. If there are more advanced (command line?) avrdude debugging options documented somewhere I'd really appreciate a link. Any other ideas also very much appreciated.

Thanks in advance for any help!

-Dave

[in0]

In order to upload, the bootloader needs to be activated. This is done by resetting the Uno's primary ATmega328P microcontroller. If that reset does not occur, you get the form of error message you encountered (though there are other potential causes of it as well).

Your Uno has an auto-reset circuit that resets the microcontroller at just the right time during the upload, so this should never happen so long as the board is in working condition and without external circuitry that interferes with the reset. But it might be worth a quick test just to see whether the error might be caused by the lack of a reset.

It is possible to activate the bootloader by manually resetting the microcontroller. You do need to get the timing right. If you press the reset button too early, the bootloader will have already timed out by the time the upload starts. The tricky thing is that when you press the "Upload" button in the Arduino IDE, it first compiles your sketch before starting the actual upload. So you need to wait until after the compilation finishes before pressing the reset button.

The way to get the timing right is to watch the black console window at the bottom of the Arduino IDE window. As soon as you see something like this:

Sketch uses 444 bytes (1%) of program storage space. Maximum is 30720 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.

press and release the reset button. The upload should now finish successfully.

Let us know what results you get from the manual reset experiment.

[dlv]

in0 thank you for your response. It happens so fast in the IDE I extracted the command line and ran it this way to better time the reset with the upload.

I ran it with higher verbosity (-v -v -v -v):

/Users/dveach/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/bin/avrdude -C/Users/dveach/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/etc/avrdude.conf -v -v -v -v  -patmega328p -carduino -P/dev/cu.usbmodem5D101 -b115200 -D -Uflash:w:/var/folders/gb/nb_350cn6w9d7jkqlpw0d93w0000gn/T/arduino_build_929559/Blink.ino.hex:i

Without hitting reset and got same results of running in IDE. 10 timeout retries.

Then I reset just as it started sending data and the output was much different.

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/Users/dveach/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/etc/avrdude.conf"
         User configuration file is "/Users/dveach/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodem5D101
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
avrdude: Send: A [41] . [80]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: A [41] . [81]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: A [41] . [82]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: A [41] . [98]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
         Hardware Version: 133981499
         Firmware Version: -406421616.32766
         Topcard         : STK502
avrdude: Send: A [41] . [84]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: A [41] . [85]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: A [41] . [86]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: A [41] . [87]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: A [41] . [89]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
         Vtarget         : 3266.8 V
         Varef           : 3.2 V
         Oscillator      : 0.001 Hz
         SCK period      : 35553.4 us

avrdude: Send: A [41] . [81]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: A [41] . [82]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [04] . [00] . [00] . [00] . [80] . [00]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: Send: Q [51]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

avrdude done.  Thank you.

I will keep trying reset with the command line approach to see if I get lucky on timing. If this is the issue. I thought maybe that additional output might help.

Thanks again.

[dlv]

Ok just for info for anyone who wants to know. I am convinced now this is an OS problem with Catalina 10.15.6 after more testing and finding a work around.

I knew I had serial comm working with with this board with a loopback test. The fact that the port showed up as "Arduino Uno" in the IDE and I could get board info also seemed to indicate serial comm was working. I also knew the board and the cable were good by using them on another computer. So the IDE recognized the Uno but Avrdude just couldn't talk to the confirmed good programmer. Something must be wrong with the FTDI driver in this OS or something else related to that.

To confirm this I created a Linux (Ubuntu) VM in VirtualBox on this Mac Pro running Catalina and installed the Arduino IDE. The exact same Uno board plugged into the same USB port on the Mac Pro with the same cable. I just enabled the Arduino Uno USB port to the VM in VirtualBox, loaded the blink example and viola! It uploaded just fine. No reset button presses or anything. Just works like it should.

I'm surprised there isn't more on the forums about this issue with Catalina (and Big Sur?). I did hit a few links on the web about it but no solution. Technically I haven't fixed my actual Mac OS issue but just worked around it with the Box VM. Pretty ugly workaround but I can live with it.

One last note: I also ran across a post somewhere (I lost it) that said Arduino IDE board uploads were "broken" under Catalina and beyond because something wasn't compiled into the IDE and that installing Xcode would fix it. I tried that but didn't help me.

Hope this helps in some way.

[in0]

@dlv

Something must be wrong with the FTDI driver in this OS

From the identification of the board in the screenshots of the Arduino IDE Tools > Port and Tools > Board info, I can tell that your Uno has an ATmega16U2 USB to serial adapter chip (as is the case with all official Unos as well as any true clones). Since the board uses that USB chip instead of the FTDI FT232R like on the official classic Nano, the FTDI driver is not relevant to your board.

[dlv]

Thanks in0. It must be something else then. That explains why trying to update the FTDI drivers in Catalina didn't help any either. I'm moving on from attempting to resolve this further since I have a workaround to do the Arduino work I want to do on this system.

However, it is my belief this issue isn't unique to my environment given what I've seen. I'm willing to provide further information about my system if anyone should want it for more investigation.

Cheers