AVR32 support

[sillydan1]

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 the AT32UC3A0512 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:

avrdude error: uP_table neither knows mcuid -1 nor part AT32UC3C0512C
avrdude error: avrintel.c does not hold configuration information for AT32UC3C0512C

Doing some digging, it seems that the culprit is a lookup in an autogenerated table in avrintel.c. However, it seems that the autogenerated avrintel.c file is not being updated on compilation. According to the comment, these files are autogenerated by the perl script called mkavrintel.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):

#------------------------------------------------------------
# AVR32UC3C0512C
#------------------------------------------------------------

part # uc3c0512c
    desc                   = "AT32UC3C0512C";
    id                     = "uc3c0512c";
    variants               =
        "AT32UC3C0512C-ALUR:    LQFP144,  Fmax=66 MHz, T=[-40 C, 85 C], Vcc=[1.65 V, 3.6 V]",
        "AT32UC3C0512C-ALUT:    LQFP144,  Fmax=66 MHz, T=[-40 C, 85 C], Vcc=[1.65 V, 3.6 V]";
    prog_modes             = PM_AVR32JTAG | PM_aWire;
    signature              = 0x00 0x00 0x3f;

    memory "flash"
        paged              = yes;
        offset             = 0x80000000; 
        size               = 0x00080000;
        page_size          = 128;
        num_pages          = 1024;
    ;
;

I am using an AVRDragon as my programmer, and yes, I have a good, solid connection.

[mcuee]

Previously the idea is to forget about AVR32 support as it is not popular.

[sillydan1]

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 😭 (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.

[stefanrueger]

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?)

• Carefully designs the avrdude.conf entries
• These entries are a complete coverage of the uc3 parts that AVRDUDE currently can (in principle) program; I am sure we don't want to add new parts every few months

We 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.

[sillydan1]

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. 😞

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 😄
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

error.log

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.

[stefanrueger]

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