Reward for solution to "protocol error" when flashing ATmega328P on macOS 11.6

[deplorables]

I have the same issue as Error while burning boot loader (Atmega328p).

The following procedure works without issue in Windows 7 & 10, as well as Mac OS 10.13 &10.14. However, the procedure does NOT work in Mac OS 11.6 (I haven't tested in 10.15 or 12.x).

The following items are identical:
-All hardware, including the computer, the Arduino, the cabling, etc.
-All "test files", including avrdude, the device hex file to upload, the ArduinoAsISP.hex file, etc. I'm literally downloading the same zip file onto each OS version and running it.
-The avrdude commands, which I am running in Terminal.

Here are the commands I run on each OS version:
0: navigate to directory:
cd <directory of unzipped file>

Result: Works as expected.

...

1: Write ArduinoAsISP:
avrdude -v -p atmega328p -b 115200 -c arduino -P /dev/cu.usbmodem1311 -D -Uflash:w:"/Volumes/RAM Disk/ArduinoAsISP.hex":i -u

Result: Works as expected.

...

2: Write downstream hex file onto DUT:
'avrdude -C "/Volumes/Test/avrdudemac.conf" -v -p atmega328p -b 19200 -c stk500v1 -U flash:w:"/Volumes/testfw328p.hex":i -P /dev/cu.usbmodem1311 -u`

Result:
Mac OS 10.13 & 10.14, and Windows 7 & 10:
Works as expected.

Mac OS 11.6 (incorrect):
avrdude fails to upload the firmware, returning (in summary):
stk500_getparm(): (a) protocol error, expect=0x10, resp=0x14
stk500_getparm(): (a) protocol error, expect=0x14, resp=0x02
stk500_getparm(): (a) protocol error, expect=0x14, resp=0x10
'...`

The only difference is the operating system. Everything else is the same (hardware, avrdude, config file, ArduinoAsISP, etc). I've tried this with multiple different computers, multiple different hardware setups, etc... in fact, several people at my company have tried this on their dev hardware/machines with identical results.

My guess is this is a timing issue that's caused by the OS itself.

"Have I tried adding a 10 uF capacitor?" In short, no... because we have ~QTY30,000 units deployed in the field, so not a practical solution.

[deplorables]

I am offering a $200 (USD) reward to the first person to solve the issue outlined above.

This reward is payable upon meeting the following conditions:
1: Must resolve the issue in software. The hardware is known-working in Windows 7 & 10, as well as Mac OS 10.13 & 10.14.
2: Solution must work in Mac OS 11.6.
3: Solution must load firmware onto a 32M1 microcontroller with the following hardware setup: USB<->16U2(Uno)<->328p(Uno)<->32M1(shield).

I will try any and all avrdude commands posted here. If you post the magical string(s) that solves this issue, I will send you $200 USD (e.g. Paypal, Amazon purchase, etc).

Here are our working avrdude calls in Mac OS 10.13:
1: Load 328p with ArduinoAsISP (working):
avrdude -v -p atmega328p -b 115200 -c arduino -P /dev/cu.usbmodem1311 -D -Uflash:w:"/Volumes/RAM Disk/ArduinoAsISP.hex":i -u

2: Load 32M1 firmware (not working in Mac OS 11.6, but working in Win7/Win10/Mac10.13/etc):
avrdude -C "/Volumes/Test/avrdudemac.conf" -v -p atmega328p -b 19200 -c stk500v1 -U flash:w:"/Volumes/testfw328p.hex":i -P /dev/cu.usbmodem1311 -u

3: Load 328p firmware (working):
avrdude -v -p atmega328p -b 115200 -c arduino -P /dev/cu.usbmodem1311 -D -Uflash:w:"/Volumes/RAM Disk/deviceFirmware.hex":i -u

FYI: I'm 99% sure this is a timing issue with avrdude in 11.6. So bonus points if you figure out the root cause (although I'm happy to use any workaround you can dream up).

[westfw]

I have the same issue.

There's no particular sign that this is "the same issue", especially since it seems to involve a MacOS version dependency...

Moderator: this should probably move to "Jobs and paid consulting" or at least to a separate thread in "Bootloader Issues"

@deplorables

Solution must load firmware onto a 32M1 microcontroller with the following hardware setup: USB<->16U2(Uno)<->328p(Uno)<->32M1(shield).

that's an odd combination. Can you provide a copy of the hardware ? Do you see the same problem with, say, some other AVR on a breadboard?

As it happens, my Macs are all running 10.x or 12.x - do you see the same issue with a Mac running 12.x?

"Have I tried adding a 10 uF capacitor?" In short, no.

I've always disabled Reset on the Uno with the cap when programming external devices. I've seen rumors that it's supposed to work without a cap, but I've always been unsure...

Is is permissible to change the ArduinoAsISP sketch? Or replace it with something else? What about replacing it with a sketch that specifically updates the 32m1 firmware without requiring avrdude use? (How big is the 32m1 firmware?)

I have split the post out to a dedicated topic under the "Jobs and Paid Consultancy" forum category as suggested.

Best wishes for success with your endeavors @deplorables
pert

[6v6gt]

@deplorables

"Have I tried adding a 10 uF capacitor?" In short, no... because we have ~QTY30,000 units deployed in the field, so not a practical solution.

Can you supply a link to the instructions you give your end users for updating the firmware of this board.

[cedarlakeinstruments]

You have a problem affecting 30,000 fielded units but a solution is worth approximately one hour of an engineer's time?

[deplorables]

@westfw

Is is permissible to change the ArduinoAsISP sketch? Or replace it with something else? What about replacing it with a sketch that specifically updates the 32m1 firmware without requiring avrdude use? (How big is the 32m1 firmware?)

Yes, modifying ArduinoAsISP sketch is allowed. Replacing that sketch is also allowed. However, we do need to be able to stream the actual 32M1 firmware from the host (not via building it into the derivative "ArduinoAsISP" hex file).

@westfw

Can you provide a copy of the hardware ?

Here's the shield schematic:

GrBLDC%20Schematic%20-%20RevC.pdf

It plugs into a standard Arduino Uno. The SPI interface (from Uno's 328p to 32M1 on shield) is signals "64M1_RST", "64M1_MOSI", "64M1_MISO", and "64M1_CLK" on connector P1 (quadrant B7).

@6v6gt

Can you supply a link to the instructions you give your end users for updating the firmware of this board.

The Firmware update is automatically performed by our software. Our user simply pushes the "update firmware" button. Behind the scenes we just send commands to avrdude.

@cedarlakeinstruments

You have a problem affecting 30,000 fielded units but a solution is worth approximately one hour of an engineer's time?

Incorrect. We have QTY30000 fielded units, but less than QTY50 deployed units are used with computers running the affected operating system (Mac OS 11.6). In other words, QTY29550 deployed units are working just fine, and the QTY50 'affected' units would work just fine if our users switched to a different operating system.

Sounds like this isn't a task you're up for at the stated rate. Typically I would recommend countering with a "more reasonable" offer, but I get that you're (probably) just passing through.

@rupawalaebrahim

This is exactly what I thought too.

And the worst thing is it has been presented as a competition where "winner gets the prize money". So apparently we are expected to participate in here, put all that effort only to find out 'somebody did it faster than you'....

No thanks, that's not how engineering services work.

If you want to ink a contract, let me know your terms.
I'm 99% certain this is an actual issue with avrdude... so while I agree I'm asking for help to solve 'my' problem, in reality I believe this affects ALL community members that attempt to DFU using avrdude and a downstream MCU via ArduinoAsISP.

My $200 solicitation was simply to encourage the community to solve this avrdude problem. And I'm certain it's an actual avrdude problem.

[deplorables]

Clarification: The reason I "only" offered $200 for a solution is that I suspect this is a one-line fix. My thought is that an "avrdude expert" would chime in with a one-line response like:
"oh, hey, you need to add -E example:solution to the avrdude call", and then everything would just work and I'd say "cool, thanks for spending one minute to fix that, here's your $200."

FYI: I am a consulting engineer, too. But I spend countless hours each month offering free support online. Also, everything I design is open source, including the product mentioned above.

All this is to say: if $200 doesn't meet your budget, or if you think this is more than a few minutes worth of work, let me know your hourly rate.

[westfw]

@deplorables

while I agree I'm asking for help to solve 'my' problem, in reality I believe this affects ALL community members that attempt to DFU using avrdude and a downstream MCU via ArduinoAsISP.

That is what makes it interesting - the idea that something is broken with the MacOS11/Avrdude/ArduinoAsISP path that will potentially affect lots of people. (and perhaps somewhere "timing" is so sensitive that we're just lucky that more, similar, paths haven't broken.)

[westfw]

Hmm. I was going to provide a modifed avrdude, but I'm having trouble getting the automated build working

You haven't provided feedback that would have been useful:

1. Do you have the same problem with MacOS 12?
2. Do you have the same problem programming less mysterious chips, on a breadboard?

[deplorables]

Sorry I haven't replied in a bit...
I was a bit discouraged by the responses in this thread thus far. Note that I didn't actually create this separate thread (or its title), whose wording was I guess a bit off-putting to this community.

Anywho, I'm just now getting back into tacking this issue. I've just loaded Big Sur onto my test machine and will report back later... this time around I've got the logic analyzer out, so I should be able to see if there's a physical timing issue.