Open sillydan1 opened 2 months ago
Previously the idea is to forget about AVR32 support as it is not popular.
Previously the idea is to forget about AVR32 support as it is not popular.
That makes sense. The uc3c
family is officially obsoleted by Microchip and the latest compatible gcc major version is...... 4 :sob: (latest major release at time of writing is 14).
If the concern is about testing hardware, we have plenty that is using the uc3c
family at my job and we are doing nightly tests and we are quite tired of using the official programmer application since it tends to mess up, so perhaps we could assist in that department. I would have to talk to my boss about it, but I expect it to not be a problem.
If the official plan is to completely remove AVR32 support, then I would suggest to rip out as many mentions as possible (i.e. the AT32UC3A0512
config and the PM_AVR32JTAG
program mode) to prevent red herrings.
Regardless. How do I add a new MCU when I can't run the mkavrintel.pl
script? Should I just manually edit the table? If so, what values should I add? - I have the appropriate .adtf files, so if it's just a matter of translating the values, then it should be possible.
avrdude has a distinct focus on 8-bit AVR.
The one 32-bit uc3
probably was a trial. However, we tend to not remove support from sth that used to be supported.
I don't think the current maintainers have uc3
boards hardware to test, so the previous pre-release tests certainly did not include those parts. We therefore don't know whether the current AVRDUDE works with the single one part that is defined (AT32UC3A0512). If it doesn't let us know in a separate issue with the command-line used and the AVRDUDE response and a log file that you get when using the option -vvvl error.log
. It looks(!) like only flash programming was every supported. If we can get that to run, I would be open to bringing all other compatible parts of the uc3
family into the fold (but other maintainers might have a different opinion). This would be on the understanding that no new AVRDUDE functionality is needed and that someone else (you @sillydan1?)
uc3
parts that AVRDUDE currently can (in principle) program; I am sure we don't want to add new parts every few monthsWe probably can get away not assigning an mcuid
to the uc3
parts, as these are only really needed for functionality beyond flash programming (interrupt lists, register file info, disassembly, ...). This may require a few tweaks in AVRDUDE so it doesn't complain or stop when uc3
parts don't have that mcuid
.
If it turns out there is no easy way to resurrect uc3
flash programming, we probably should remove that.
We have a handful of products (for the curious, this is one of them) that is using uc3
chips.
Specifically, we are using AT32UC3C0512C
and AT32UC31512C
, but we don't have boards with any of the other chips in the uc3
family, so we wont be able to add the entire uc3
family.
I have talked to my boss about this, and we (sadly) don't have the resources available to lift additional maintenance tasks on this. The plan is to continue to use the official (outdated, and frankly quite buggy) avr32program
application provided by Microchip instead. :disappointed:
If any future historians are reading this conversation, you can download the .atdf
files here:
http://packs.download.atmel.com/Atmel.UC3C_DFP.1.0.77.atpack
You may close this issue and mark as wontfix
if you'd like.
Regardless, I think it would be a good idea for avrdude to remove the AT32UC3A0512
from the config, just to be transparent about the fact that AVR32 is officially not supported. But that is ultimately up to you guys :smile:
I did a quick run to test if the AT32UC3A0512
config would produce the same error that I am seeing (i.e. that avrintel.c
is missing an entry):
avrdude -c dragon_jtag -p uc3a0512 -t -vvvl error.log
# then just ctrl+d to exit terminal mode
It seems that it produces the same error. So it looks like it would make a lot of sense to just remove the config entry.
As an aside, I have used avrdude on 8-bit AVR on other unrelated projects, and it has been an absolute joy to use.
Thanks for the error.log @sillydan1 Although it shows an error it doesn't look like the error is fatal. The bleeding edge avrdude built from git main might show a warning (probably not even that) but certainly not an error.
Can you try reading/writing to that part, say by writing a simple .hex file to flash memory (-U blink.hex
) or dumping flash memory to a file (`-U flash:r:file.hex:I)? Ideally using the latest avrdude from git main. Just to see whether AVR32 r/w to flash works
I am trying to add a new MCU to the list of supported parts. Specifically, I am trying to add the
AT32UC3C0512C
MCU, which is (sorta) similar to theAT32UC3A0512
which is already in the default config, so I (perhaps naively) assume that it should be somewhat straight forward to add. However, when I try to use my initial config, I get an error:Doing some digging, it seems that the culprit is a lookup in an autogenerated table in
avrintel.c
. However, it seems that the autogeneratedavrintel.c
file is not being updated on compilation. According to the comment, these files are autogenerated by the perl script calledmkavrintel.pl
, but during my research, I found this and this comment which indicate that the script is simply not available, and doesn't seem to ever will be.If this is the case, I am left to wonder:
How do I even add a new MCU, when the script that is required to use is not available?
Personally, I don't mind unreadable code, so publishing a required, but messy perl script is astronomically better than leaving it as "an exercise for the reader", so to speak.
P.S. I noticed that the
AT32UC3A0512
MCU is not in the autogenerated table either. Is this on purpose?P.P.S. For the curious, my initial config is (obviously not working yet):
I am using an AVRDragon as my programmer, and yes, I have a good, solid connection.