Closed ProxyPlayerHD closed 1 year ago
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
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?
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..
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.
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
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...
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.
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: @.***>
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: @.***>
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.
anyways, since the main issue is resolved i'll be closing it.
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)
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…]()
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:
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?