AVR128DA64/AVR64DA64
March 26, 2026 ยท View on GitHub
Pin Mapping / Pinout
Features and Peripherals
| - | AVR64DA64 | AVR128DA64 |
|---|---|---|
| Flash Memory | 65536 | 131072 |
| Flash Memory (With Optiboot) | 65024 | 130560 |
| SRAM | 8192 | 16384 |
| EEPROM | 512 | 512 |
| User Row | 32 | 32 |
| Max. Frequency (rated, MHz) | 24 | 24 |
| Clock Sources | INT, EXT, XTAL | INT, EXT, XTAL |
| Packages Available | TQFP, VQFN | TQFP, VQFN |
| Total pins on package | 64 | 64 |
| I/O Pins (not reset/UPDI) | 54 | 54 |
| Fully async pins | 13 | 13 |
| UPDI as I/O Pin | No | No |
| PWM capable I/O pins | 46 | 45 |
| Max simultaneous PWM outputs | 19: 12+2+5 | 19: 12+2+5 |
| 16-bit Type A Timers - pins ea | 2: 42, 18 | 2: 42, |
| 16-bit Type B Timers, (pins) | 5: 10 | 5: 10 |
| 12-bit Type D pins | 4 | 4 |
| USART (pin mappings) | 6: all 2 | 6: all 2 |
| SPI (pin mappings) | 2: 3/3 | 2: 3/3 |
| TWI/I2C (pin mappings) | 2: 3/3 | 2: 3/3 |
| 12-bit ADC input pins | 22 | 22 |
| Of those, neg. diff. inputs | 16 | 16 |
| 10-bit DAC | 1 | 1 |
| Analog Comparator (AC) | 3 | 3 |
| Zero-Cross Detectors (ZCD) | 3 | 3 |
| Custom Logic Blocks (LUTs) | 6 | 6 |
| Event System channels (out pins) | 10: 13 | 10: |
| On-chip opamps (OPAMP) | - | - |
| MVIO, pins | No | No |
| Flash Endurance | 1k | 1k |
| LED_BUILTIN (and optiboot led) | PIN_PA7 | PIN_PA7 |
* As with all Dx-series, the flash didn't live up to expectations at extreme conditions. 1k is the worst case rating though, and under typical conditions, it is believed that the endurance is >= 10k cycles. I do not know how far along Microchip is in developing a solution, but it's being treated as datasheet clarification, so that's not encouraging. I am hoping for additional information on how flash endurance is influenced by various factors.
DA64 - the baseline 64-pin Dx-series part
No MVIO, No OPAMPS. 64-pins gets the last USART, ZCD, and TCB, plus an extra pinset for each SPI port, and 2 for TWI1. This is a much smaller step-change than 32-48, though peripheral density remains high by historical standards. There is no 32k flash version. The 128k version is afflicted particularly badly by errata.
Fully async pins
Pins 2 and 6 within each port are "fully async" and can respond to events shorter than 1 clock cycle, and can wake the chip on RISING or FALLING edges, not just LOW_LEVEL and CHANGE. The rest are "partially async" and can only respond to "low level" or "change" if there is no system clock running (all interrupt triggers will work if the I/O clock is running due to an RUNSTBY that requests it or because you are only in idle sleep mode).
USART mux options
| All | TX | RX | XCK | XDIR |
|---|---|---|---|---|
| DEFAULT | Px0 | Px1 | Px2 | Px3 |
| ALT1 | Px4 | Px5 | Px6 | Px7 |
Px refers to a port:
| USART | PORT |
|---|---|
| 0 | PORTA |
| 1 | PORTC |
| 2 | PORTF |
| 3 | PORTB |
| 4 | PORTE |
| 5 | PORTG |
SPI mux options
| SPI | Swap name | MOSI | MISO | SCK | SS |
|---|---|---|---|---|---|
| SPI0 DEFAULT | SPI0_SWAP0 | PA4 | PA5 | PA6 | PA7 |
| SPI0 ALT1 | SPI0_SWAP1 | PE0 | PE1 | PE2 | PE3 |
| SPI0 ALT2 | SPI0_SWAP2 | PG4 | PG5 | PG6 | PG7 |
| SPI1 DEFAULT | SPI1_SWAP0 | PC0 | PC1 | PC2 | PC3 |
| SPI1 ALT1 | SPI1_SWAP1 | PC4 | PC5 | PC6 | PC7 |
| SPI1 ALT2 | SPI1_SWAP2 | PB4 | PB5 | PB6 | PB7 |
The SPI library only makes one SPIClass object available (see The SPI.h library documentation for details).
TWI0 mux options
| Mapping | swap | Master or Slave | Dual Mode Slave |
|---|---|---|---|
| DEFAULT | 0 | SDA/PA2 SCL/PA3 | SDA/PC2 SCL/PC3 |
| ALT1 | 1 | SDA/PA2 SCL/PA3 | SDA/PC6 SCL/PC6 |
| ALT2 | 2 | SDA/PC2 SCL/PC3 | SDA/PC7 SCL/PC7 |
TWI1 mux options
| Mapping | swap | Master or Slave | Dual Mode Slave |
|---|---|---|---|
| DEFAULT | 0 | SDA/PF2 SCL/PF3 | SDA/PB2 SCL/PB3 |
| ALT1 | 1 | SDA/PF2 SCL/PF3 | SDA/PB6 SCL/PB7 |
| ALT2 | 2 | SDA/PB2 SCL/PB3 | SDA/PB6 SCL/PB7 |
PWM Pins
48-pins is an exciting breakpoint for PWM: You get another half dozen PWM pins from the second TCA1!
- TCA0 is by default set to PORTC. This is a decision I would have made differently had I owned a crystal ball during the design process; but by the time the DBs had arrived with MVIO on PORTC (hence a poor pick for default pins for PWM), the core had been released and we don't like to break backwards compatibility. It's not much of an issue now that you can trivially switch the ports at runtime. I now think that PORTG is the obvious right choice.
- TCA1 is by default set to PORTB, the only port on which it can have 6 pins on 48-pin DA's
- TCD0 is left at the default pins on PORTA, because they are the only ones that work.
- The 4 type B timers are set for PF4, PF5, PC0 and PC1, and this cannot be changed at runtime. Note that the millis timer cannot be used to generate PWM. TCB2 is the default millis timer, though this can be changed from the tools menu.
- This gives 6 + 6 + 2 + 5 = 19 PWM channels simultaneously outputting PWM. 42/54 pins (78%) can output PWM from TCA0, and 9 or 18 (16.7 or 33.3%) from TCA1, with 8 or 16 (14.8% or 29.6%) having two TCA options.
TCA mux options
The Type A timers (TCA0 and TCA1) can be mapped to different pins as a group only, and analogWrite() is PORTMUX-aware - you can set TCA0 to output on any port's pin 0-5, and TCA1 to PORTB. Using this feature is easy - but not quite as trivial as other parts, since there are two bitfields. You simply write to the portmux register PORTMUX.TCAROUTEA = (TCA1 pinset << 3) | (TCA0 pinset) and then analogWrite() normally. TCA0 pinset is the port number (0-5 for ports A-F), TCA1 pinsets are from the table below, with numeric values of 0x00, 0x08, 0x10 and 0x18 (It is recommended to use the named constants however, as shown in the example).
| TCA0 | WO0 | WO1 | WO2 | WO3 | WO4 | WO5 |
|---|---|---|---|---|---|---|
| PORTA | PA0 | PA1 | PA2 | PA3 | PA4 | PA5 |
| PORTB | PB0 | PB1 | PB2 | PB3 | PB4 | PB5 |
| PORTC | PC0 | PC1 | PC2 | PC3 | PC4 | PC5 |
| PORTD | PD0 | PD1 | PD2 | PD3 | PD4 | PD5 |
| PORTE | PE0 | PE1 | PE2 | PE3 | PE4 | PE5 |
| PORTF | PF0 | PF1 | PF2 | PF3 | PF4 | PF5 |
| PORTG | PG0 | PG1 | PG2 | PG3 | PG4 | PG5 |
| TCA1 | WO0 | WO1 | WO2 | WO3 | WO4 | WO5 |
|---|---|---|---|---|---|---|
| PORTB | PB0 | PB1 | PB2 | PB3 | PB4 | PB5 |
| PORTC | PC4 | PC5 | PC6 | - | - | - |
| PORTE | PE4 | PE5 | PE6 | - | - | - |
| PORTG | PG0 | PG1 | PG2 | PG3 | PG4 | PG5 |
The PORTG and PORTE mux options are not available on the AVR128DA64 due to errata, this erratum is not listed for 128DB or 64DA/DB parts. This was part of a pair of errata specific to the 128k 64-pin parts which betrayed the fact that the most testing and development was done on the 48-pin parts: both of these busted mux options are present only on 64-pin parts; the other errata was that the event system on wasn't connected to PB6/7 or PE4-7. That is, they forgot to add the connections to the pins that weren't used on the 48-pin parts). These were both corrected almost immediately internally - and did not impact any of the subsequent parts (128DA was the first Dx-family). Though two, possibly three die revs of the DA-series exist, one of which appeared some time after the initial release and well after parts where this was fixed had been shipping, none of these revisions corrected any of the known errata. It would be interesting to decap a DA Rev A6, A7, and A8. Even with crude methods, a major change to the fab process used (maybe a die shrink) would be apparent from differences in the size and color (the shiny colored surface of the die is a product of the microscopic structure) of the die.
If one found that A8 dice were smaller or a different color - okay, A8 was just a die shrink. If there were NOT such changes, one wonders what the difference between the die revs is - my mind would immediately turn to the possibility that there was some secret bug that was both very simple to fix, and didn't involve touching the buggy parts of the chip. I received some AVR128DA64's in mid 2023, and I expect that they will be A8's. I suspect that "gross process differences" like a die shrink could be detected by setting a CCL to invert it's own output with no synchronization and output to a pin, which is what I plan to do. This results in a MUCH higher frequency oscillation than the system clock, and involves behavior which is not constrained by the specs other than that that we know it's fast, because async things are described as potentially being shorter than a clock cycle and still detected.
It is strongly recommended to not have any PWM output enabled involving either the timer being moved nor the pins it is being moved to when setting PORTMUX.TCAROUTEA. In the latter case, you will not be able to turn off the existing PWM through the API functions.
PORTMUX.TCAROUTEA = PORTMUX_TCA0_PORTF_gc | PORTMUX_TCA1_PORTB_gc; // PWM on PORTF and PORTB pins 0-5
PORTMUX.TCAROUTEA = (PORTMUX.TCAROUTEA & PORTMUX_TCA1_gm) | PORTMUX_TCA0_PORTD_gc; // Move TCA0 PWM to PORTD but don't change TCA0
// The first option is slightly faster, as it isn't a read-modify-write. You almost always want TCA1 mux to be set to PORTB on a 128k parts
// Note that PORTMUX_TCA0_PORTA_gc and PORTMUX_TCA1_PORTB_gc have a numeric value of 0. So for the common case, you can use simple assignment to set
// PORTMUX.TCAROUTEA to PA, PB, PC, PD, PE, or PF.
// If you know what the other option is, it's more efficient to use the first construction (3 words of flash, 3 clocks) than the second (6 words, 7 clocks).
TCB mux options
| TCBn | Default | Alt |
|---|---|---|
| TCB0 | PA2 | PF4 |
| TCB1 | PA3 | PF5 |
| TCB2 | PC0 | PB4 |
| TCB3 | PB5 | PC1 |
| TCB4 | PG3 | PC6 |
These are NOT PORTMUX-aware. Only the bold pin can be used without modifying or creating a new variant file. TCAs take priority over TCBs, so without changing the TCA0 mapping, TCB2/TCB3 are not used.
The type B timers are much better utility timers than PWM timers. TCB2 is the default millis timer and cannot be used for PWM in that mode. This configuration is recommended. See the Timer Reference for more information
TCD0 mux options
| TCD0 | WOA | WOB | WOC | WOD |
|---|---|---|---|---|
| DEFAULT | PA4 | PA5 | PA6 | PA7 |
| ALT1 | ||||
| ALT2 | ||||
| ALT3 |
The Type D timer, TCD0, has 2 output channels (WOA and WOB) and 4 output pins (WOA, WOB, WOC, and WOD). The hardware permits WOC and WOD to each output either WOA or WOB, but this added too much complexity to analogWrite; WOA and WOC output WOA, and WOD and WOB output WOB. Calling analogWrite() on either pin will enable it, calling digitalWrite() on that pin will turn the PWM off. Calling analogWrite() on WOC while already outputting on the WOA pin will result in both pins outputting the new duty cycle. Call digital write on first pin if this is not what you want. The datasheet describes TCD0 output on PA4-7, PB4-7, PF0-3, and PG4-7. What the datasheet giveth, the errata taketh away: the alternate pin options are hopelessly broken on the DA(S) and will remaain so until we get the major die rev that the DB got.
LED_BUILTIN
Following precedent set by MegaCoreX, we declare that pin 7 - PIN_PA7 shall be the pin that the core "expects" to be connected to an LED. LED_BUILTIN is defined as that pin, and the bootloader will set that pin as output and try to blink the LED. Note that if the bootloader is not used, and your sketch does not reference LED_BUILTIN this pin is not otherwise treated any differently. If you want to have a different pin be recognized by the application (this does not change the bootloader - you would still need to do a custom build of that too), this can be overridden if a custom board definition is created by passing -DLED_BUILTIN=(some other pin) as part of build_extra_flags, building via the CLI, or by equivslent means provided by other third party development environments.
Reset pin can be input
Reset (PF6) can be set to work as an input (but never an output). The UPDI pin cannot be configured as an I/O pin.
ADC pins in differential mode
Only pins on PORTD and PORTE can be used as the negative side of a differential analog reading (analogReadDiff(), see Analog Reference). Pins on PORTF can be used as positive or single ended ADC inputs only.
Official Documentation
When all else fails, read the real documentation. They keep moving the .pdf files around, so now I just link to the prduct page, from whence the datasheet, errata, and "technical briefs".
Datasheets and errata change. You can sign up to get emails about such changes through the Microchip PCN system; if you don't, be sure to always use the latest version of the datasheet and especially the errata
Note: The DA-series has 3 datasheets, one for each flash size. Despite a non-trivial amount of effort, I have found no substantive differences except those resulting from the different headings indicating the product covered. It baffles me why they feel a need to produce and maintain three copies of an identical datasheet. Things which do not apply to the 32k parts are in some cases still listed anyway. The errata is not quite the same between the flash sizes - the 128k ones were released first, and caught the most bugs.
BE SURE TO REVIEW THE ERRATA - OR AT LEAST OUR SUMMARY OF IT - the DA-series has a lot of significant errata in all available versions as of Q1 2025.
It is recommended to keep a copy of the IO headers open if manually configuring peripherals too (open it in something with good search, like notepad++ or sublime - notepad is not up to the task. When you're trying to find out what convoluted name the clocksource bitfields of the TCA CLKSEL, a quick regex search for TCA.*CLKS (CLKS is better than CLKSEL: 'wait, ws it CLKSRC or CLKSEL?' - point is, you'll need to look up some difficult to spell and type correctly constant name sooner or later if you're working outside the Arduino API; you'll likely be much happier copy-pasting the half-a-line-long name than retyping it.
If you're going far too deep, be sure to bring a copy of the AVR bible and keep it ready at a moment's notice.
In addition to the datasheet, unfortunately, you definitely cannot get away without the silicon errata and datasheet clarification document in addition to the latest version of the datasheet - that is the document that lists silicon bugs and which die revs and parts they're present on; if they list something as an "Erratum" that means that, in theory, maybe, some day, silicon without any of the errata will be available, but I'm not confident it will happen before the sun runs out of fuel and puffs up into a red giant, engulfing the inner planet. That last part would cause problems for terrestrial semiconductor manufacturers as well as their customers. (Yeah, with all that radiation, process yields would tank... "And staffing problems too, what with the extermination life on the planet" That too. It would really shake things up, for sure)... Anyway, as of early 2025, the DB and the EA have received die-revs that make a difference (no other part hasBoth the DB and EA have now (the former due to it being the flagship and having a lot of very visible bugs. The latter because they did something horribly wrong with the self-programming system there. Datasheet clarifications are a bigger deal than an erratum, usually. An erratum says "Okay, this doesn't work, but it will some day, maybe" while a datasheet clarification says "This would be an errata, but we're not even going to pretend that we'll fix it some day". But watch out - datasheet clarifications vanish from the list once the datasheet has been updated!
The "Technical Briefs" are somewhat inconsistent in their value, but some are quite good.