Summary: Add support for UPDI and AVR8X
Project: AVR Downloader/UploaDEr
Submitted by: je_ruud
Submitted on: Thu 09 Nov 2017 09:30:56 AM UTC
Priority: 5 - Normal
Assigned to: None
Discussion Lock: Any
Add support for the UPDI interface. This programming and debugging interface
is used in the AVR8X (2017->) series of devices and is supported in JTAGICE3,
AtmelICE, EDBG, mEDBG, nEDBG and PowerDebugger.
Specification is located here: (will post a link when it finally goes public)
By adding support for UPDI it opens up for supporting the AVR8X range of
devices; ATtiny212 - ATtiny416 - ATtiny817 - ATtiny1617 - ... (To be
Working with the device configuration for the AVR8X devices I'm struggling a
bit with offsets. With AVR8X things like eeprom, fuses and lockbits are no
longer in separate address spaces, they're mapped in the data address space.
(EEPROM at 0x1400, fuses at 0x1280,...) These offsets should be mapped in the
.conf file in my opinion, but how? I could add a new "mapped_offset", but
where is the current memory offset used? Could that be reused for this?
I thought the memory offset in the .conf file was related to where the gcc
linker maps content like eeprom, but from what I can see the linker uses
0x810000 for eeprom while avrdude uses 0x8c0000.
Could somebody enlighten me, please?
The offsets used in the linker scripts are based on historical
decisions, to merge all the distinct AVR Harvard address spaces
into a single, flat 32-bit address space which used to be the
default for GNU tools. That's where the 0x810000 for the
EEPROM comes from. The GNU tools use 0 through 0x800000 for
Flash, allowing for up to 8 MiB of flash. SRAM then starts
at 0x800000 (but is not of interest for AVRDUDE).
However, with the advent of the Xmega and PDI, the tools need
to talk to the NVM controller. The NVM controller uses a
different 32-bit address space model to map the Xmega's
individual memory regions. For an example, see Figure 30-3
in the Xmega A datasheet:
After digging a bit through the ATtiny816 datasheet, it doesn't
seem the UPDI uses something like the memory offsets that can
be seen in the Xmega PDI.
Note that the GNU tools offsets (0x810000 for EEPROM etc.) are
only relevant when reading directly from an ELF file. They are
supposed to already be correctly handled in AVRDUDE's ELF loader,
so don't need to be taken care of later on.
Figure 6-1 in the ATtiny817 datasheet suggests we might need
to apply an offset of 0x8000 when programming flash, as the
CPU's address 0 maps to an UPDI address 0x8000.
My toolchain hasn't been updated yet to handle the ATtiny817.
Could you perhaps an ELF file flashing a LED on the Xplained Pro
kit I could use as a starting point for tests?
When programming flash over UPDI the flash offset is set up in the device
context. So when writing to flash memory you start at address 0x0000. For the
other memories you use absolute address. FUSES start at 0x1280, EEPROM start
So then I guess it actually makes sense to use the offsets in avrdude.conf for
these values. It simplifies things quite a bit.
> Follow-up Comment #5:
> Thanks a lot, good work!
> Just committed to SVN, with only few changes (white space only).
Let me introduce Jan Egil Ruud to the rest of the audience.
Jan Egil works for Microchip (former Atmel) in Trondheim, Norway. He
submitted a larger patch that adds the UPDI protocol to AVRDUDE, a
variant of the PDI protocol used by the Atmel/Microchip tools for
UPDI applies to a new device family labelled AVR8X. This is kind of
an "Xmega scaled down to Tiny level", so to speak. It inherits a lot
from the Xmega family (including the basic programming protocol), but
everything is scaled down for small devices.
Jan Egil's patch has been in really good shape now, so after a bit of
review and testing, I decided that it's time to get it into the SVN
repository. Any remaining issues can be discussed here.
cheers, Joerg .-.-. --... ...-- -.. . DL8DTL