Enhancement: stk500v2 with uPDI

[mcuee]

@ElTangas has a customized uPDI programmer which is based on STk500v2. https://github.com/ElTangas/STK2UPDI

Maybe the support of this programmer can be added to avrdude.

avrdude has already supported jtag2updi. https://github.com/ElTangas/jtag2updi

[MCUdude]

@ELtangas may correct me here, but he did write in an Avrfreaks forum post that stk2updi was a hack, and the jtagmkii protocol was better suited.

Hi, stk2updi was just an hack and I'm not developing it anymore. I just occasionally update jtag2updi.

[ElTangas]

Indeed, it's a hack. I don't recommend it to be used or added to avrdude. It was just an experiment, superseded by jtag2updi.

The stk500v2 protocol is simply not suited for UPDI (or xmega's PDI for that matter).

[MCUdude]

The stk500v2 protocol is simply not suited for UPDI (or xmega's PDI for that matter).

Out of curiosity, the AVRISPmkII using the STK500v2 protocol when communicating with xmega's using PDI, isn't it? Xmegas have multiple fuses just like chips with UPDI, and apparently, the AVRISPmkII works great with xmegas, so what makes the STK500V2 protocol unsuited for UPDI?

[mcuee]

Indeed, it's a hack. I don't recommend it to be used or added to avrdude. It was just an experiment, superseded by jtag2updi.

I see. I will close this one.

But as @MCUdude mentioned, STK500V2 seems to be fine to for PDI. So maybe it is also good for uPDI.

[ElTangas]

Well I'm not familiar with AVRISP mkII. From what I can find it uses a different protocol that does look similar to STK500v2: https://ww1.microchip.com/downloads/en/Appnotes/doc8015.pdf

But the real reason STK500v2 is unsuitable for xmega and UPDI can be seen in the way the chips are defined in avrdude.conf.

If you look at the definition of a classic AVR such as mega328p you will find lots of stuff such as

    read            = "  1   0   1   0      0   0   0   0",
                      "  0   0   0   0    a11 a10  a9  a8",
                      " a7  a6  a5  a4     a3  a2  a1  a0",
                      "  o   o   o   o      o   o   o   o";

    write           = "  1   1   0   0      0   0   0   0",
                      "  0   0   0   0    a11 a10  a9  a8",
                      " a7  a6  a5  a4     a3  a2  a1  a0",
                      "  i   i   i   i      i   i   i   i";

These commands are required by stk500v2. PDI and UPDI just work in a different way and don't use these command sequences at all.

A UPDI chip requires both memory addresses and memory types to be defined for example:

memory "flash"
    size      = 0x20000;
    offset    = 0x800000;
    page_size = 0x200;
    readsize  = 0x100;
;

memory "eeprom"
    size      = 0x200;
    offset    = 0x1400;
    page_size = 0x1;
    readsize  = 0x100;
;

You can see the formats are totally different, as is the information they convey. The jtagice mk2 protocol allows this information, required for PDI and UPDI, to be passed easily. To shoehorn this information into a stk500 type format would undoubtedly require ugly hacks.

Avrdude already has enough hacks if you ask me. One of them is the way in which the memory type is inferred from the memory region name, which is undocumented btw.

[mcuee]

You can say that AVRISP mkii is using STK500v2 protocol for ISP. STK500 V2 FW has not been updated for very long (since 2006?) and it does not support PDI. AVRISP mkii more updated firmware and supports PDI. The PDI part is not covered in the STK500v2 (and seems also the AVR069 pdf file, probably the same as STK600.

Ref: stk500.exe supports both STK500 and AVRISP mkii. https://microchipsupport.force.com/s/article/Commandline-utility-for-STK500-and-AVRISP-mkII

Ref: STK600 Communication protocol has the PDI XPROG protocol. http://ww1.microchip.com/downloads/en/Appnotes/doc8133.pdf

BTW, STK600 seems to support uPDI but not documented above. http://ww1.microchip.com/downloads/en/devicedoc/40001904a.pdf

Ref: FW history of AVRISP mkii https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42093-AVR-ISP-mkII_UserGuide.pdf

1.3. What's New
1.3.1. October, 2015 - Atmel Studio 7.0 - FW 01.18
• Fixed issue when reading voltage before TPI operations
1.3.2. August, 2013 - Atmel Studio 6.1 Update 2 - FW 01.17
• Bug fixes
1.3.3. April, 2013 - Atmel Studio 6.1 - FW 01.16
• Increased TPI clock speed
• Bug fixes
1.3.4. November, 2011 - AVR Studio 5.1 - FW 01.11
• Improved PDI stability
1.3.5. December 11th, 2009 - AVR Studio 4.18 SP1
• Added TPI support
1.3.6. June 27th, 2008 - AVR Studio 4.14 SP1 - FW 01.0B
• Added PDI support
...