AVR128DB32/AVR64DB32/AVR32DB32
March 26, 2026 ยท View on GitHub
Pin Mapping / Pinout
Features and Peripherals
| - | AVR32DB32 | AVR64DB32 | AVR128DB32 |
|---|---|---|---|
| Flash Memory | 32768 | 65536 | 131072 |
| Flash Memory (With Optiboot) | 32256 | 65024 | 130560 |
| SRAM | 4096 | 8192 | 16384 |
| EEPROM | 512 | 512 | 512 |
| User Row | 32 | 32 | 32 |
| Max. Frequency (rated, MHz) | 24 | 24 | 24 |
| Clock Sources | INT, EXT, XTAL | INT, EXT, XTAL | INT, EXT, XTAL |
| Packages Available | TQFP, VQFN | TQFP, VQFN | TQFP, VQFN |
| Total pins on package | 32 | 32 | 32 |
| I/O Pins (not reset/UPDI) | 25 | 25 | 25 |
| Fully async pins | 7 | 7 | 7 |
| UPDI as I/O Pin | No | No | No |
| PWM capable I/O pins | 23 | 23 | 23 |
| Max simultaneous PWM outputs | 11: 6+2+3 | 11: 6+2+3 | 11: 6+2+3 |
| 16-bit Type A Timers - pins ea | 1: 21 | 1: 21 | 1: 21 |
| 16-bit Type B Timers, (pins) | 3: 5 | 3: 5 | 3: 5 |
| 12-bit Type D pins | 4 | 4 | 4 |
| USART (pin mappings) | 3: 2/1/2 | 3: 2/1/2 | 3: 2/1/2 |
| SPI (pin mappings) | 2: 1/1 | 2: 1/1 | 2: 1/1 |
| TWI/I2C (pin mappings) | 2: 2/1 | 2: 2/1 | 2: 2/1 |
| 12-bit ADC input pins | 13 | 13 | 13 |
| Of those, neg. diff. inputs | 7 | 7 | 7 |
| 10-bit DAC | 1 | 1 | 1 |
| Analog Comparator (AC) | 3 | 3 | 3 |
| Zero-Cross Detectors (ZCD) | 1 | 1 | 1 |
| Custom Logic Blocks (LUTs) | 4 | 4 | 4 |
| Event System channels (out pins) | 8: 7 | 8: 7 | 8: 7 |
| On-chip opamps (OPAMP) | 2 | 2 | 2 |
| MVIO, pins | Yes, 4 | Yes, 4 | Yes, 4 |
| Flash Endurance | 1k | 1k | 1k |
| LED_BUILTIN (and optiboot led) | PIN_PA7 | 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.
DA32 - the improved 32-pin Dx-series part
This is a DA32 with MVIO, OPAMPs and crystal support instead of the TCA. The MVIO also costs it PD0, which is sort of in the middle of everything. They are still a compelling series of parts, but without the shock and awe that accompany the 48-pin parts, or the low pincount DD-series, both of which have a higher density of peripherals and better mux options.
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 |
| NONE | - | - | - | - |
Px refers to a port:
| USART | PORT |
|---|---|
| 0 | PORTA |
| 1 | PORTC |
| 2 | PORTF |
USART1 hence has no alternate pin mapping, as it has only PC0-3
SPI mux options
| SPI | Swap name | MOSI | MISO | SCK | SS |
|---|---|---|---|---|---|
| SPI0 DEFAULT | SPI0_SWAP0 | PA4 | PA5 | PA6 | PA7 |
| SPI1 DEFAULT | SPI1_SWAP0 | PC0 | PC1 | PC2 | PC3 |
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 |
| ALT2 | 2 | SDA/PC2 SCL/PC3 | SDA/PC7 SCL/PC7 |
Note that this means that you want Wire.swap(0, 2, but not 1).
TWI1 mux options
| Mapping | swap | Master or Slave | Dual Mode Slave |
|---|---|---|---|
| DEFAULT | 0 | SDA/PF2 SCL/PF3 | Not avail. |
Note that this means that you do not want to call Wire1.swap() on a 32-pin DA/DB.
PWM Pins
- TCA0 is by default set to PORTD to match the DA-series. This is painful, since it loes a PWM pin - but we can easily switch those at runtime.
- TCD0 is left at the default pins on PORTA, because they are the only ones that work.
- The 3 type B timers are set for PA2, PA3, and PC0, 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 + 2 + 3 = 11 PWM channels simultaneously outputting PWM, more than half of the total on the part!
TCA mux options
The Type A timer TCA0, 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. You simply write to the portmux register PORTMUX.TCAROUTEA = (TCA0 pinset) and then analogWrite() normally. TCA0 pinset is the port number (0-5 for ports A-F).
| TCA0 | WO0 | WO1 | WO2 | WO3 | WO4 | WO5 |
|---|---|---|---|---|---|---|
| PORTA | PA0 | PA1 | PA2 | PA3 | PA4 | PA5 |
| PORTC | PC0 | PC1 | PC2 | PC3 | - | - |
| PORTD | - | PD1 | PD2 | PD3 | PD4 | PD5 |
| PORTF | PF0 | PF1 | PF2 | PF3 | PF4 | PF5 |
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_PORTA_gc // PWM on PORTA
// Note since there is only one TCA, you can use simple assignment to write values to PORTMUX.TCAROUTEA to.
Note that this differs from both the hardware default, as well as what would be the obvious correct port for the PWM pins under most conditions (PORTF is obviously better than PORTD (though not for all cases, for example, if you need three USARTS and >4 TCA PWM pins, it's PORTD, or buy a chip with more pins) - but not all; In fact, if you need the OPAMPs, you can't exactly put it on PORTD because that's where the opamps are. The hardware defaults to PORTA.
TCB mux options
| TCBn | Default | Alt |
|---|---|---|
| TCB0 | PA2 | PF4 |
| TCB1 | PA3 | PF5 |
| TCB2 | PC0 | PB4 |
These are NOT PORTMUX-aware. Only the bold pin can be used without modifying or creating a new variant file.
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 |
| ALT2 |
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 currently, only PA4-7 work.
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 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. On parts with more pins, PORTE can also be used for negative inputs.
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
At a minimum, everyone using a modern AVR should plan on having a PDF viewer open with the datasheet, and a text editor with a good search function and the ioavr______.h file open so that when you're trying to use a constant, but the compiler says it isn't declared/defined, you can search the io header for a key phrase in the constant and figure out how it was spelled/formatted or copy/paste it to your sketch. (see the IO headers for more information and links to them. I also keep the AVR instruction set manual ("the AVR bible" - full of wisdom and truth from the creators, cloaked in confusing and obtuse verbiage, much of which seems anachonistic and difficult to apply to modern times. Seriosuly it's not that bad though - the hardest part for me is that they insist on using symbols for logic operations and I'm sorry, I can't remember whether up and down arrows are and and or, vs or and and. or what the circle divided into quarters is) open in the PDF viewer as well as the "silicon errata and datasheet clarification" document. You can skip the instruction set manual if neither writing assembly or reading your assembly listings for optimization purposes.
The "silicon errata and datasheet clarification" is an extremely important document details lists and gives a terse description of ways in which they know that the hardware they are shipping does not behave as the datasheet describes. Both phrases are euphemisms. "Silicon Errata" are bugs in the hardware, which the manufacturer admits and agrees are incorrect behavior, and comes with a rarely fulfulled promise of a silicon revision to correct them. A "workaround" which may or may not be useful may by listed, or they may say "None". The workaround line may or may not be an accurate mirror on reality. For example, a "This feature does not work" erratum might have "Workaround: Do not use this feature" (not much of a workaround). But - for once - this goes both ways. An erratum listed as having no workaround occasionally in fact has a workaround. On he DA and DB, whichever pin the ADC is pointed at has it's digital input buffer disabled. All you need to to to work around that is set the ADC mux to point to something that's not a pin except when using it (that's what we do). I suspect a tunnel vision effect is in evidence here - in that example, I suspect that the problem was noticed in the context of trying to read the digital value of the pin while analog measurement was ongoing, so engineering was not thinking "Why the hell would anyone do that?!" but "Gee, yeah, there's no way you could do that", and nobody realized that there's a far more common case: the ADC is enabled, but not in use, and you may be doing other things with the pin..
Now a Datasheet Clarification - that's a bit more serious. They are also usually silicon bugs, though technical miscommunication is not a non-issue. The key difference is that an erratum indicates that the intended fix involves changing the die, while Datasheet Clarification involves changing the datasheet to say that the current behavior is correct. On the one hand the average datasheet clarification is less severe than the average erratum. On the other hand, that's not to say there aren't nasty ones in there too.
Technical briefs
Technical briefs are what Microchip calls the sort of documents that most of the industry refers to as "app notes". Technical brief is an apt term, as it covers the wide range of usefulness and detail that can be seen in the technical briefs: Some of these are briefs as in a briefing, like what would be given to a military commander for making strategic decisions, and are highly useful. Other "technical briefs" are simply "brief", that is, short. This is not always bad, but sometimes a technical brief ends up FAR too brief and covers a topic that deserves considerably more discussion (the "product brief" is the extreme of this - in the past what is now called a "product brief" may have been called a "datasheet summary". There are also nn unfortunate few of the "technical briefs" that are even less helpful. Here the name is still apt, but in this case, it's in the sense of the article of clothing of that name: they cover the ass ("Yeah, we have a technical brief explaining that functionality"), but achieve little more. While they may be a starting point, you'd need a lot more to go anywhere.
These three broad classes are likely correlated with the knowlede and skill of their authors. Some tech briefs are written by people who really know how the feature works at a very deep level, resulting in useful informative (yet occasionally cryptic - I think this happens when people who aren't tech writers by trade get order to write a public facing document after the documentation group has tried and failed to write a useful tech brief, so even after being edited for readability by tech writers and after the censors have gone over it and redacted anything too revealing, the core of the document is written by an engineer. Most engineers are poor at clearly communicating with people who aren't steeped in the jargon and who don't think like engineers. And since the tech writer knows they don't understand it, when they can't parse an oddly phrased sentence, they leave it as is. But this isn't universal - there are good clear tech briefs... and the less-clear ones are usuallty of great value when you do finally make sense of them
The other classes are, I suspect correspond to - for the midrange - to things written by pepoeple who do really understand the peripheral, but little experience with using it except following the instructions from the engineers, which is very different than having solved a problem with it. These abstract tech briefs are less likely to be useful, but they do occasionally tell you the key "This is the the right way to do it" for a problem that you would have approached from a less effecftive direction. And the bad ones? Written by people who don't understand what their writing about, lack guidance from anyone who does, but aren't going to let that make tem miss a deadline.
A fair portion of tech briefs are essentially useless (and the list often shows tech briefs not even related to modern AVRs which are particularly useless - but there are also some really insightful and solid ones that are of great utility. They cannot be distinguished without reading them, but once you start reading, you very rapidly will realize which kind you have.