-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misleading error message when specifying wrong AVR-Ex part #1813
Comments
Hello, as usual, I would ask for verbose output ('-vvvv') for each of these commands, I need to see the exact communication happening. I must say this looks very, very weird and I don't think I could replicate it easily... |
OK, here the output of
And here the output of
Thanks for looking into this |
And, just for comparison, the output when the command line is corrected to
And here the output when the target was switched to an AVR64EA28 (and matches with the following command line):
|
@stefanrueger sorry, but I don't have good news for you, this is something that can't really be fixed. See, the problem is that when initiating connection with the MCU using SerialUPDI the signature is read from arbitrary location in memory. For AVR16EBxx chips SIGROW memory is at 0x1080, while for AVR64EAxx chips it's 0x1100. This is why when you specify incorrect part but with identical memory map (and most of these guys use 0x1100: https://github.com/avrdudes/avrdude/blob/main/src/avrdude.conf.in#L20263) then AVRDUDE reads the correct signature and responds with reasonable error proposing correct part. In your case it reads from a totally different memory (0x1100 in AVR16EBxx is BOOTROW), gets meaningless data and doesn't know how to recover from this, nor is able to suggest anything else. If there was any way to ask the chip for its memory map, we could do it instead, but unfortunately, no such option is available AFAIK. Let me know if my explanation is not clear, I will try to explain it better. |
@dbuchwald Great analysis. Thanks. OK, it's like writing the title of a book onto one of two different page numbers (or more than two ... depending on how many different memory layouts Microchip is going to entertain in future), which makes it a bit hard for the reader to figure out what the title of the book is. @askn37 Do you have more insight into how, given a UPDI chip, the signature can be read unambiguously? Is there some info in the 0x1080 is used as memory address for the AVR-DU and AVR-EB parts: run |
AFAIK, only the AVR-DU and AVR-EB has their signature at 0x1080, and these are the only chips with NVMv4 and NVMv5. So the SIB could be read to determine the NVM version, and then figure out the correct address if Avrdude is reading the signature as 0xffffff. BTW this is also a problem for jtag3 based programmers as well:
|
When taking a closer look at the jtag3 and serialupdi source code, it appears that these programmers reads the SIB before reading the device signature. So after a failed signature read attempt (signature does not start with 0x1e), we may use the NVM version number to find the correct offset for the signature/prodsig memory. When trying to read an AVR16EB32 when an AVR128DA32 is connected, I'm getting this weird signature. So a check against 0x1e may be a suitable solution.
|
This problem of poor part selection cannot be solved unless you read UPDI_SIB before reading PROD_SIGNATURE to determine the NVM version. Currently, the only protocols (as far as I know) that actually support this are SerialUPDI and JTAGmk3. Microchip has added modern UPDI support to these, but it is not documented. On the other hand, older protocols such as JTAGmk2 and STK600 do not define a mechanism to return UPDI_SIB to AVRDUDE and are not maintained by Microchip at all. Older programmers will need their own extensions to add modern support. For example, JTAG2UPDI and UPDI4AVR firmware read UPDI_SIB before reading PROD_SIG to assist with subsequent operations. This is because there is no publicly known mechanism for AVRDUDE to inform firmware of the NVM version. For UPDI4AVR only, with a small change to avrdude.conf, you can signal the NVM version and control information via unused areas in the device descriptor to support correct high-voltage programming. This is really something special. |
My take on the idea to base the error message on the NVM controller version is that we shouldn't do it. Given all the inconsistencies between latest AVR chips and their respective NVM controllers I wouldn't be surprised if that wasn't the last case we saw. All of these "ifs/elses" will end up being unmanageable spaghetti that nobody understands and everyone is afraid to remove even after NVM v3/v5 chips are no longer produced nor sold. I see that kind of tech debt in my work daily and I see how it gradually slows down value delivery to a grinding halt. That being said, if you want me to implement this feature I will do so, it's just that my instinct tells me it's not a good idea. |
Thanks all round @dbuchwald @MCUdude @askn37 for input. I feel we definitely have to do something, if only to change the error message to add "check whether the part is correctly specified". Right now, one of the recommendations is I also feel that AVRDUDE could give better advice than telling the user to specify the correct part number (the gadget housing the MCU may be difficult to open, the printing on the MCU illegible, the user may simply misremember but be convinced it is the wrong part). When given the wrong Another fun fact: There must have been a similar problem in the past b/c there is code in Lines 1575 to 1603 in a3e4c80
Anyone know what this was about? |
The family ID is pretty much useless. It started out with I suggest mentioning that the user should double check the |
I have a perfectly set up programmer (a shiny new SerialUPDI since you asked) that's connected to an AVR-Ex part.
If I mistype which part it is, I get the following misleading error message:
Actually, it's a different part, and as soon as I type the correct line it works:
Notwithstanding that the error was between the chair and the keyboard, why could AVRDUDE not read the signature and could AVRDUDE have done any better in its error message? @dbuchwald might have some insights.
The text was updated successfully, but these errors were encountered: