Programming an ATTiny424 with Arduino

[bathtub-toast]

Is the expected behavior for the bootloader to to use the python3 with prog.py and the upload sketch to use avrdude?

Asking as avrdude never seems to get a connection to my attiny424 chip and only gives me this error.
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x30
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x30
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x30
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x30
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x30
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x20

Doing a verbose the bootloader gets:
C:\Users\username\AppData\Local\Arduino15\packages\megaTinyCore\tools\python3\3.7.2-post1/python3 -u C:\Users\username\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.11/tools/prog.py -t uart -u COM12 -b 230400 -d attiny424 --fuses 0:0x00 1:0b00010110 2:0x01 5:0b11110110 6:0x05 7:0x00 8:0x02 -fC:\Users\username\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.11/bootloaders/hex/optiboot_tx2z_1sec.hex -a write -v

while any sketch gets this:
C:\Users\username\AppData\Local\Arduino15\packages\DxCore\tools\avrdude\6.3.0-arduino17or18/bin/avrdude -CC:\Users\username\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.11/avrdude.conf -v -pattiny424 -carduino -D -PCOM12 -b115200 -Uflash:w:C:\Users\username\AppData\Local\Temp\arduino_build_803314/code.ino.hex:i

None of the notes I found said anything about needing to swap from UPDI to UART for programming, so the behavior is unexpected.

Exporting the code as a hex and trying to load it manually with the python3 prog.py makes me feel that I don't understand what its doing at all. this is after burning the bootloader
C:\Users\username\AppData\Local\Arduino15\packages\megaTinyCore\tools\python3\3.7.2-post1/python3 -u C:\Users\username\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.11/tools/prog.py -t uart -u COM12 -b 230400 -d attiny424 -fC:\Users\username\Documents\Arduino\code\code.ino.t424opti.1c0.mB1.v2511.hex -a write -v

output.txt

[SpenceKonde]

When "Uploading" a sketch, the board's definition of it's upload pins (potentially optiboot serial pins) - assuming those are specified (they aren't for non-bootloader boards of course) - are used to determining what kind of "programmer" (in this case a bootloader that acts like a programmer. During these uploads the selected tools -> programmer option ignored.

When "Upload using Programmer" or "Burn Bootloader" is used, those commands request an operation when cannot be performed through a bootloader. Hence, the selected programmer (from Tools -> Programmers) i used

[bathtub-toast]

Ok, that makes sense to me.

I now see that I picked 'poorly' and that's why I was getting frustrating errors using Upload using Programmer, I initially missed that there was 2 places that I could select my ATTiny424 at. Picking the one without w/Optiboot fixed a bunch of issues I didn't realize I was having.

Just by changing that, now it defaults to using the prog.py for either upload option.

Thank you for all of you patience and assistance.

[SpenceKonde]

That's why we put the non-optiboot options at the top of the list ;-)
You might also want to read the relevant part-specific docs for the part you're using, I do believe it advises against a botloader for all 14 pin parts...

[bathtub-toast]

I'm guessing that you mean where it says optiboot is 'not recommended' on this page for the x24 chips

and my preference is no bootloader, but it was part of my testing process for 'why can't I upload my code?' since I should expect the bootloader to fail uploading in the same spectacular fashion as my code was failing.

However, you pointed out where my mistake was, and now I can load code without a bootloader. I appreciate your assistance in helping me think a bit more in a different direction and sort out the issue I was having.