Problems burning the bootloader (SerialUPDI)

[ProxyPlayerHD]

some back story, when the AVR DB-Series was just released i made a simple arduino-like board for the AVR128DB48, with onboard FT232RL and the arduino reset circuit with the ~DTR pin. i also put optiboot on it as soon as i could to program it like a regular arduino board. (without needing to press the reset button every time i programmed it)

that was a while ago, so i decided to re-burn the bootloader as it has likely been updated a few times at this point. but i can't seem to be able to get it to work.

i tried with the jtag2updi method which i used previously to burn the first bootloader. but that just gives me some weird error that i sadly didn't save. so now i'm trying to use the much simplier SerialUPDI method. i'm using a 1N5819 schottky diode and a 470 Ohm resistor to the UPDI pin on my board, and a CP2102 based USB to UART adapter.

when it click "burn bootloader" the whole process takes a fraction of a second (even using the 57600 baud option), the IDE says "done burning bootloader" in the corner, and the USB to UART adpater has the "USB" LED constantly on (or flashing really really fast). i don't think that's right though. should it be that fast on the slowest setting? and the log doesn't indicate that it actually wrote any data, only setting and checking fuses:

UPDI programming for Arduino using a serial adapter
Based on pymcuprog, with significant modifications
By Quentin Bolsee and Spence Konde
Version 1.3.0.2 - Jun 2023
Using serial port COM8 at 57600 baud.
Target: avr128db48
Set fuses: ['0:0b00000000', '1:0x00', '2:0x00', '5:0b11001001', '6:0b00001101', '7:0x00', '8:0x00']
Action: erase
pymcuprog.programmer - INFO - Setting up programming session for 'avr128db48'
pymcuprog.deviceinfo.deviceinfo - INFO - Looking for device avr128db48
pymcuprog.serialupdi.physical - INFO - Opening port 'COM8' at '57600' baud
pymcuprog.serialupdi.link - INFO - STCS 08 to 0x03
pymcuprog.serialupdi.link - INFO - STCS 06 to 0x02
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
pymcuprog.serialupdi.link - INFO - UPDI init OK
pymcuprog.serialupdi.link - INFO - STCS 06 to 0x02
pymcuprog.serialupdi.link - INFO - Setting UPDI clock to 4 MHz
pymcuprog.serialupdi.link - INFO - STCS 03 to 0x09
pymcuprog.serialupdi.physical - INFO - Switching to '57600' baud
pymcuprog.serialupdi.application - INFO - SIB: 'AVR     P:2D:1-3M2 (A5.KV00D.0)'
pymcuprog.serialupdi.application - INFO - Device family ID: 'AVR'
pymcuprog.serialupdi.application - INFO - NVM interface: 'P:2'
pymcuprog.serialupdi.application - INFO - Debug interface: 'D:1'
pymcuprog.serialupdi.application - INFO - PDI oscillator: '3M2'
pymcuprog.serialupdi.application - INFO - Extra info: '(A5.KV00D.0)'
pymcuprog.serialupdi.application - INFO - Using 24-bit UPDI
pymcuprog.serialupdi.link - INFO - STCS 08 to 0x03
pymcuprog.serialupdi.link - INFO - STCS 06 to 0x02
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
pymcuprog.serialupdi.link - INFO - UPDI init OK
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
pymcuprog.serialupdi.application - INFO - PDI revision = 0x03
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.application - INFO - Entering NVM programming mode
pymcuprog.serialupdi.link - INFO - LDCS from 0x07
pymcuprog.serialupdi.application - INFO - Apply reset
pymcuprog.serialupdi.link - INFO - STCS 59 to 0x08
pymcuprog.serialupdi.application - INFO - Release reset
pymcuprog.serialupdi.link - INFO - STCS 00 to 0x08
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.nvm - INFO - No specific initializer for this provider
Pinging device...
pymcuprog.programmer - INFO - Reading device ID...
pymcuprog.serialupdi.application - INFO - SIB: 'AVR     P:2D:1-3M2 (A5.KV00D.0)'
pymcuprog.serialupdi.application - INFO - Device family ID: 'AVR'
pymcuprog.serialupdi.application - INFO - NVM interface: 'P:2'
pymcuprog.serialupdi.application - INFO - Debug interface: 'D:1'
pymcuprog.serialupdi.application - INFO - PDI oscillator: '3M2'
pymcuprog.serialupdi.application - INFO - Extra info: '(A5.KV00D.0)'
pymcuprog.serialupdi.application - INFO - Using 24-bit UPDI
pymcuprog.serialupdi.link - INFO - STCS 08 to 0x03
pymcuprog.serialupdi.link - INFO - STCS 06 to 0x02
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
pymcuprog.serialupdi.link - INFO - UPDI init OK
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
pymcuprog.serialupdi.application - INFO - PDI revision = 0x03
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.application - INFO - Device ID = '1E970C' rev 'A5'
pymcuprog.nvm - INFO - Device ID: '1E970C'
pymcuprog.nvm - INFO - Device revision: 'A5'
pymcuprog.nvm - INFO - Device serial number: 'b'420501196000851201550125''
Ping response: 1E970C
Setting fuse 0x0=0x0
Writing literal values...
pymcuprog.programmer - INFO - Write...
pymcuprog.programmer - INFO - Writing 1 bytes of data to fuses...
pymcuprog.serialupdi.nvm - INFO - NVM EEPROM erase/write command
pymcuprog.serialupdi.nvm - INFO - Clear NVM command
pymcuprog.programmer - INFO - Write complete.
Verifying literal values...
pymcuprog.programmer - INFO - Reading 1 bytes from fuses...
pymcuprog.programmer - INFO - Verifying...
Action took 0.02s
Setting fuse 0x1=0x0
Writing literal values...
pymcuprog.programmer - INFO - Write...
pymcuprog.programmer - INFO - Writing 1 bytes of data to fuses...
pymcuprog.serialupdi.nvm - INFO - NVM EEPROM erase/write command
pymcuprog.serialupdi.nvm - INFO - Clear NVM command
pymcuprog.programmer - INFO - Write complete.
Verifying literal values...
pymcuprog.programmer - INFO - Reading 1 bytes from fuses...
pymcuprog.programmer - INFO - Verifying...
Action took 0.02s
Setting fuse 0x2=0x0
Writing literal values...
pymcuprog.programmer - INFO - Write...
pymcuprog.programmer - INFO - Writing 1 bytes of data to fuses...
pymcuprog.serialupdi.nvm - INFO - NVM EEPROM erase/write command
pymcuprog.serialupdi.nvm - INFO - Clear NVM command
pymcuprog.programmer - INFO - Write complete.
Verifying literal values...
pymcuprog.programmer - INFO - Reading 1 bytes from fuses...
pymcuprog.programmer - INFO - Verifying...
Action took 0.02s
Setting fuse 0x5=0xc9
Writing literal values...
pymcuprog.programmer - INFO - Write...
pymcuprog.programmer - INFO - Writing 1 bytes of data to fuses...
pymcuprog.serialupdi.nvm - INFO - NVM EEPROM erase/write command
pymcuprog.serialupdi.nvm - INFO - Clear NVM command
pymcuprog.programmer - INFO - Write complete.
Verifying literal values...
pymcuprog.programmer - INFO - Reading 1 bytes from fuses...
pymcuprog.programmer - INFO - Verifying...
Action took 0.02s
Setting fuse 0x6=0xd
Writing literal values...
pymcuprog.programmer - INFO - Write...
pymcuprog.programmer - INFO - Writing 1 bytes of data to fuses...
pymcuprog.serialupdi.nvm - INFO - NVM EEPROM erase/write command
pymcuprog.serialupdi.nvm - INFO - Clear NVM command
pymcuprog.programmer - INFO - Write complete.
Verifying literal values...
pymcuprog.programmer - INFO - Reading 1 bytes from fuses...
pymcuprog.programmer - INFO - Verifying...
Action took 0.02s
Setting fuse 0x7=0x0
Writing literal values...
pymcuprog.programmer - INFO - Write...
pymcuprog.programmer - INFO - Writing 1 bytes of data to fuses...
pymcuprog.serialupdi.nvm - INFO - NVM EEPROM erase/write command
pymcuprog.serialupdi.nvm - INFO - Clear NVM command
pymcuprog.programmer - INFO - Write complete.
Verifying literal values...
pymcuprog.programmer - INFO - Reading 1 bytes from fuses...
pymcuprog.programmer - INFO - Verifying...
Action took 0.02s
Setting fuse 0x8=0x0
Writing literal values...
pymcuprog.programmer - INFO - Write...
pymcuprog.programmer - INFO - Writing 1 bytes of data to fuses...
pymcuprog.serialupdi.nvm - INFO - NVM EEPROM erase/write command
pymcuprog.serialupdi.nvm - INFO - Clear NVM command
pymcuprog.programmer - INFO - Write complete.
Verifying literal values...
pymcuprog.programmer - INFO - Reading 1 bytes from fuses...
pymcuprog.programmer - INFO - Verifying...
Action took 0.02s
Finished writing fuses.
Chip/Bulk erase,
Memory type eeprom is conditionally erased (depending upon EESAVE fuse setting)
Memory type flash is always erased
Memory type lockbits is always erased
...
pymcuprog.programmer - INFO - Erase...
pymcuprog.serialupdi.nvm - INFO - Chip erase using NVM CTRL
Erased.
Action took 0.02s
pymcuprog.serialupdi.application - INFO - Leaving NVM programming mode
pymcuprog.serialupdi.application - INFO - Apply reset
pymcuprog.serialupdi.link - INFO - STCS 59 to 0x08
pymcuprog.serialupdi.application - INFO - Release reset
pymcuprog.serialupdi.link - INFO - STCS 00 to 0x08
pymcuprog.serialupdi.link - INFO - STCS 0C to 0x03
pymcuprog.serialupdi.physical - INFO - Closing port 'COM8'

i did try to use the board normally afterwards (uploading the blink program) but it simply doesn't respond when uploading, so i'm sure the bootloader isn't present on the chip...

so what am i missing here?

[SpenceKonde]

what is pin PA7 (nominally the LED) doing? it should be giving the triple blink repeatedly

What message do you get on upload? You're not trying to upload with the serial port still connected to the UPDI adapter right? to program that way you don't use the bootloader.

The successful bootloader burn seems to imply successful write updi write (though that's a much beefier diode than needed - there's no problem there. What's the error when uploading? Do you have the serial pins connected right? Tx to Rx, DTR or RTS connected to one side of a 0.1uF cap, other side connected to reset, reset connected by a 10k resistor to Vdd and small signal diode with the band pointed towards Vdd. (this diode is of more importance than ever, because it could otherwise boost the reset pin above it's absolute maximum voltage on DA, DB, and put the chip into HV mode and potentially exceed the absolute maximum on DD which isn't 12V anymore when you release RTS/DTR

[ProxyPlayerHD]

what is pin PA7 (nominally the LED) doing? it should be giving the triple blink repeatedly

when? during bootloader burning, passively while the MCU is powered, or when uploading a sketch through the UART? in either case it never blinks.

You're not trying to upload with the serial port still connected to the UPDI adapter right? to program that way you don't use the bootloader.

the SerialUPDI circuit is disconnected and i use the PA0/PA1 UART pins for regular sketch uploading

What message do you get on upload?

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

         System wide configuration file is "C:\Users\x\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.5.8/avrdude.conf"

         Using Port                    : COM9
         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=0x88
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x88
etc

the "resp" byte is pretty much random every time.

Do you have the serial pins connected right?

i'm pretty sure, like mentioned above i did have optiboot on it before and it worked perfectly fine right up to the point when i decided to re-burn the bootloader a few days ago. so i really don't think anything on the PCB could be the cause. (through i don't have that reset diode).

i also tried to upload the blink sketch using the SerialUPDI adapter but that just gives me an error as well: A programmer is required to upload so maybe that's just not supported?

here's an image of my board and SerialUPDI setup in case that could give any clues.

The successful bootloader burn seems to imply successful write updi write

true, but why does it only write fuses and erase the flash? it never says that it's writing to flash after erasing it, which would explain why the bootloader doesn't seem to do anything... as it's simply not present. or did i misread something in the log? or is that part of the process not being logged in the first place?

[SpenceKonde]

What you describe is very concerning. You do havethe right board definition selected right? The optiboot version both when burning bootloader and uploading? Otherwise since you said you didn;t want optiboot (based on board selection) it won't install it..

[SpenceKonde]

post the full error message that gaveyou that programmer is required error, i havent seen that error before and want o know the context. Also, when copying upload errors, dont use the copy error button. manually select the text, becaues the button leaves out the first line. Unfortunately the first line is about as valuable as every other line combined.

[ProxyPlayerHD]

Otherwise since you said you didn't want optiboot

i do want optiboot. that's why i've been trying to burn the bootloader.

post the full error message that gave you that programmer is required error

that was the full error message. it compiled and then just printed that one line in red.

Also, when copying upload errors, dont use the copy error button. manually select the text, becaues the button leaves out the first line. Unfortunately the first line is about as valuable as every other line combined.

i did copy it manually... for the one line error message i just left out the standard flash/RAM usage numbers.

You do have the right board definition selected right? The optiboot version both when burning bootloader and uploading?

nope. i had the "no bootloader" option selected while burning it because the chip didn't have the bootloader on it. do you have to select "AVR D*-Series (optiboot)" to be able to burn the bootloader?

i tried it with the "optiboot" variant selected, and it worked. the bootloader is now burned and i can upload sketches over USB like normal again.

.

well that was really dumb... i selected the "no bootloader" variant because it didn't have a bootloader on it after my inital try. because i thought the variants "optiboot" and "no bootloader" are supposed to be selected depending on the current state of the MCU (which for a blank chip is always "no bootloader"), not the state you want it to be in...

so honestly i feel like that's not entirely my fault for misunderstanding that, as it doesn't seem very clear from just looking at the UI.

would it be possible to atleast add a little message to the console output after "burning the bootloader" on a "no bootloader" chip? mainly to tell the user that this only erases the chip and if they want to burn optiboot they need to select the "optiboot" variant of the chip.

and maybe a small note in the REDME as well.

to prevent idiots like me from making this mistake again...

either way, thanks for the help! atleast it's working now

[SpenceKonde]

When uploading, the selected option is the current state of the chip (bootloader or no bootloader).

When bootloading, the selected option is the state of the chip that you want.

I thought I did mention it in the readme...

[ProxyPlayerHD]

it is a pretty big file. so if it was there i didn't see it, in which case sorry about that.

looking through it again i can't seem to find anything mentioning the change in function of the "burn bootloader" button depending on the chip variant selected.

[SpenceKonde]

Wiki pages?

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: @.***

On Sun, Jul 9, 2023, 16:21 ProxyPlayerHD @.***> wrote:

it is a pretty big file. so if it was there i didn't see it, in which case sorry about that.

looking through it again i can't seem to find anything mentioning the change in function of the "burn bootloader" button depending on the chip variant selected.

maybe it's a good idea to clean up the README a bit and move a lot of stuff over to some wiki pages?

— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/DxCore/issues/451#issuecomment-1627816108, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW2K7GW4S7SSQH3CA5LXPMHEJANCNFSM6AAAAAA2DAUYEQ . You are receiving this because you commented.Message ID: @.***>

[SpenceKonde]

I'll also note that the docs for the most part have been very heavily revised .....

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: @.***

On Sun, Jul 9, 2023, 16:21 ProxyPlayerHD @.***> wrote:

it is a pretty big file. so if it was there i didn't see it, in which case sorry about that.

looking through it again i can't seem to find anything mentioning the change in function of the "burn bootloader" button depending on the chip variant selected.

maybe it's a good idea to clean up the README a bit and move a lot of stuff over to some wiki pages?

— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/DxCore/issues/451#issuecomment-1627816108, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW2K7GW4S7SSQH3CA5LXPMHEJANCNFSM6AAAAAA2DAUYEQ . You are receiving this because you commented.Message ID: @.***>

[ProxyPlayerHD]

github has this feature where a repository can have it's own little wiki, with different pages and such. it's useful when you have a lot of documentation.

https://docs.github.com/en/communities/documenting-your-project-with-wikis/about-wikis

obviously moving everything to that will take work, so you'll have to decide if that's worth it yourself... also i'm sorry if i sounded condescending or similar, i know how hard writing and sorting documentation for any project is... especially if there's so much of it.

[ProxyPlayerHD]

anyways, since the main issue is resolved i'll be closing it.

[SpenceKonde]

FYI, entry conditions on all supplied bootloader binaries were totally busted on both cores until about now (github version of DxCore) and a few minutes in the future (for github version of mTC)

[hoka83]

Otherwise since you said you didn't want optiboot

i do want optiboot. that's why i've been trying to burn the bootloader.

post the full error message that gave you that programmer is required error

that was the full error message. it compiled and then just printed that one line in red.

Also, when copying upload errors, dont use the copy error button. manually select the text, becaues the button leaves out the first line. Unfortunately the first line is about as valuable as every other line combined.

i did copy it manually... for the one line error message i just left out the standard flash/RAM usage numbers.

You do have the right board definition selected right? The optiboot version both when burning bootloader and uploading?

nope. i had the "no bootloader" option selected while burning it because the chip didn't have the bootloader on it. do you have to select "AVR D*-Series (optiboot)" to be able to burn the bootloader?

i tried it with the "optiboot" variant selected, and it worked. the bootloader is now burned and i can upload sketches over USB like normal again.

.

well that was really dumb... i selected the "no bootloader" variant because it didn't have a bootloader on it after my inital try. because i thought the variants "optiboot" and "no bootloader" are supposed to be selected depending on the current state of the MCU (which for a blank chip is always "no bootloader"), not the state you want it to be in...

so honestly i feel like that's not entirely my fault for misunderstanding that, as it doesn't seem very clear from just looking at the UI.

would it be possible to atleast add a little message to the console output after "burning the bootloader" on a "no bootloader" chip? mainly to tell the user that this only erases the chip and if they want to burn optiboot they need to select the "optiboot" variant of the chip.

and maybe a small note in the REDME as well.

to prevent idiots like me from making this mistake again...

either way, thanks for the help! atleast it's working now Hello, could you explain how did you fix the error , i have the same problem to program avr128DA28 chip by arduino uno as a programmer ![Uploading IMG_6061 (1).jpeg…]()