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

[mcuee]

@sillydan1

Any updates on the suggestion from Stefan? Thanks.

[sillydan1]

Thanks for the ping! We decided to write our own specialized tool instead and I kinda forgot about this thread, sorry. This also means I can only do this in my free-time.

It seems that I unplugged my device on my desk, so I can't do the test today. I will set a reminder to do it tomorrow.

[sillydan1]

Using the latest commit on main fails:

avrdude -c dragon_jtag -p uc3c0512c -U flash:r:file.hex:I -vvvl error.log

Only changes is my chip config.

$ git diff
diff --git a/src/avrdude.conf.in b/src/avrdude.conf.in
index b9688c35..ca674b68 100644
--- a/src/avrdude.conf.in
+++ b/src/avrdude.conf.in
@@ -20968,6 +20968,28 @@ part parent ".avr8x_mega" # m4809
     ;
 ;

+#------------------------------------------------------------
+# 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;
+    ;
+;
+
 #------------------------------------------------------------
 # AVR-Dx family common values
 #------------------------------------------------------------

I just built the project using build.sh.

error.log

I havent tried writing, as it I don't want to risk bricking my device.

[klazarev]

Несмотря на это, я думаю, что было бы хорошей идеей для avrdude удалить AT32UC3A0512из конфигурации, просто чтобы быть честным относительно того, что AVR32 официально не поддерживается.

Then rename the application in avr8dude, so as not to deceive users. The AVR family is not limited to 8-bit controllers

[stefanrueger]

Thanks for testing @sillydan1! I am pretty sure the flash page size is wrong: it must be 512 bytes not 128 bytes. See data sheet:

A word here means 4 bytes, of course.

I also recommend adding readsize = 512;

Please could you try again with a corrected avrdude.conf entry? This will decide whether to change the unconfirmed label to bug.

[sillydan1]

Nicely spotted!

It still seems to not work though.

diff --git a/src/avrdude.conf.in b/src/avrdude.conf.in
index b9688c35..7615c7bf 100644
--- a/src/avrdude.conf.in
+++ b/src/avrdude.conf.in
@@ -20968,6 +20968,28 @@ part parent ".avr8x_mega" # m4809
     ;
 ;

+#------------------------------------------------------------
+# 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          = 512;
+        num_pages          = 1024;
+    ;
+;
+
 #------------------------------------------------------------
 # AVR-Dx family common values
 #------------------------------------------------------------

error.log

[stefanrueger]

@sillydan1 OK, the avrdude messages are bad response to enter progmode command: RSP_ILLEGAL_JTAG_ID and JTAGEN fuse disabled?. Is the JTAGEN fuse enabled? Have you considered the following from the Dragon user manual?

[sillydan1]

The reset line is connected, yes. Perhaps it's because the pin is negated?

[stefanrueger]

These are things that I would expect the Dragon programmer to worry about (though that wouldn't have the agency to unsolder stabilizing caps from the reset line :).

avrdude claims there are other programmers that can deal with UC3 parts

$ avrdude -pAT32UC3A0512 -c?

Valid programmers for part AT32UC3A0512 are:
  atmelice           = Atmel-ICE (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  atmelice_jtag      = Atmel-ICE (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  dragon_jtag        = Atmel AVR Dragon (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  dryrun             = Emulates programming without a programmer (TPI, ISP, PDI, UPDI, HVSP, HVPP, aWire)
  jtag2fast          = Atmel JTAG ICE mkII (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  jtag2              = Atmel JTAG ICE mkII (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  jtag2slow          = Atmel JTAG ICE mkII (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  jtag3              = Atmel AVR JTAGICE3 (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  jtagmkII           = Atmel JTAG ICE mkII (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  jtagmkII_avr32     = Atmel JTAG ICE mkII (aWire)
  jtag2avr32         = Atmel JTAG ICE mkII (aWire)
  powerdebugger      = Atmel PowerDebugger (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  powerdebugger_jtag = Atmel PowerDebugger (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  xplainedpro        = Atmel XplainedPro (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG
  xplainedpro_jtag   = Atmel XplainedPro (JTAG, XMEGAJTAG, AVR32JTAG) via AVR32JTAG

Maybe more luck with some of these?

[stefanrueger]

Or try enabling the JTAGEN fuse first using another system?

[sillydan1]

We sadly only have the AVRDragon programmer available (plenty of Digilent HS3's, but they dont seem to be AVR32JTAG compatible according to your list) I thought I saw an atmelice some weeks ago, but I can't find it currently.

The JTAGEN fuse is very likely to be enabled, as the internal tool that we built can drive the jtag no problem. Could it be that the magic initialization sequence (the screenshot from before) is not being performed?

[stefanrueger]

Could it be that the magic initialization sequence [...] is not being performed?

Would that not be done by the Dragon programmer as opposed to AVRDUDE?

[sillydan1]

Would that not be done by the Dragon programmer as opposed to AVRDUDE?

I dont think so, but on the other hand, I also dont know so either.

The official avr32program flashing program supports the avrdragon (located in the avr32-utilities-x86_64.tar.gz tarball which is provided by microchip). However, it is closed source, and my ghidra-foo is not really up to snuff to figure out if the initialization sequence is handled by the code, or by the avrdragon itself.