Solution to Arduino as ISP upload error

Development Tools Uploading
1

I had the same error as others (but their topics are closed, for example Help with error code using Arduino Nano to ATMega328P chip, or Out of Range error when burning). Let me post a solution so that people who have this error can find the answer.

When burning bootloader, or uploading using the programmer, if you have the following error:

Warning: attempt 1 of 10: not in sync: resp=0x15
Warning: attempt 2 of 10: not in sync: resp=0x15
AVR part              : ATmega328PB
Programming modes     : SPM, ISP, HVPP, debugWIRE
Programmer type       : STK500
Description           : Atmel STK500 v1

Error: protocol expects OK byte 0x10 but got 0x14

Error: protocol expects sync byte 0x14 but got 0x02

Error: protocol expects sync byte 0x14 but got 0x10

All you have to do to fix it is to replace the default speed with 115200, as the default is 19200, and leads to the incorrect values above being read.

2

Hi @jerome5. Thanks for sharing your findings!

How exactly did you do that?

Did you edit the "Arduino as ISP" programmer definition in the programmers.txt file in the platform for the board?

Did you modify the "ArduinoISP" sketch code?

3

Oh, that's a great question, I missed a critical piece of information in my post: the target is a miniCore ATmega, and the MiniCore board manager is adding a menu with the serial speed.

The issue is probably specific to using a MiniCore board behind an ArduinoISP board.

4

Thanks for the clarification. I understand now that you are referring to MiniCore's Tools > Baud rate option:

https://github.com/MCUdude/MiniCore/tree/master?tab=readme-ov-file#baud-rate-option

It might also be applicable to the other boards platforms from MCUdude that use the urboot bootloader:

5

Sorry, my "solution" did work, but doesn't work any more, and I probably had too many things changing in my tests. I don't even understand how it could do anything, given that changing the baud speed is not changing the speed at which avrdude is talking to arduinoISP.

I just want to add two things for people reading this:

  • I incorrectly assumed that the values from the error messages (0x15, 0x14, 0x14, 0x02, 0x10) were signals interpreted at a wrong speed. It's not the case. These values are perfectly normal, 0x15 means NO_SYNC, that's how the protocol gets back into sync: the software is supposed to ignore them, and get to the next bytes which are the real answers. Except that avrdude takes them as invalid responses, and sends another request, keeping being out of sync (see timeline below).
  • Commenting the line sending NO_SYNC in arduinoISP when something wrong happens (in the default: case) ends up fixing things: if avrdude doesn't ignore NO_SYNC, we can just send nothing, that's going to be ignored for sure.

For reference, here is the timeline:

image
image2001×117 5.49 KB

You can see the NO_SYNC from a previous attempt, then the requests (30 20), correctly answered with (14 10), but avrdude sees all that as wrong:

Warning: attempt 1 of 10: not in sync: resp=0x15
Warning: attempt 2 of 10: not in sync: resp=0x15
Error: protocol expects OK byte 0x10 but got 0x14
Error: protocol expects sync byte 0x14 but got 0x02
Error: protocol expects sync byte 0x14 but got 0x10