PDI support?

[MCUdude]

In your README you mentioned that PDI support may happen someday since it's similar to UPDI.
This would be really, really cool, as there are almost no DIY or community-designed AVR programmer that supports PDI. The only exception is the LUFA based AVRISPmkII, which does support PDI.

Since PDI is basically just UPDI with a clock line, wouldn't it be possible to create a "serialpdi" programmer that uses a USB to serial chip that supports synchronous serial (if that exists)?

[askn37]

@MCUdude

Since PDI is basically just UPDI with a clock line, wouldn't it be possible to create a "serialpdi" programmer that uses a USB to serial chip that supports synchronous serial (if that exists)?

Do you know of a synchronous clock-enabled USART-USB converter that would allow this? Potentially, some RS485 conversion chips should be able to do this, but the biggest barrier was the availability of Windows drivers.

On the other hand, if you look for USB-enabled microcontrollers that can support synchronous clock and RS485, you will find that there are very few. They don't exist in STM or ESP. There doesn't seem to be a single ARM series that can use synchronous clock. On the other hand, the only AVR series that can do this was the ATxmega-AU family. However, even the smallest one is expensive with QFP-44P, and unfortunately it is a PDI type. It is not widespread, so you can't find a properly maintained open source environment for it.

The UPDI type series, even the smallest ATtiny202, fully supports synchronous clock and RS485. This means that if you support serial communication-based JTAGICEmkII, you can also create a PDI programmer. But no one has tried it. Even in the open hardware world, PDI is really becoming forgotten.

Finally, the AVR-DU family has been released, which meets the necessary hardware requirements. With USB functionality, full RS485 support with synchronous clock, I2C and SPI conversion, you are free to create a completely versatile USART-USB converter. You are free to choose the VID:PID, and if you ignore the license, you are free to choose the Windows driver.

Also, if I can support EDBG/CMSIS-DAP, I will mimic pkobn and pickit4 to make them available in AVRDUDE's jtag3.c and usb_hidapi.c. That's my contribution to the open source.

The stub for the PDI interface is already present in the current source code. However, I won't be working on it for a while, because HV control has a higher priority.

[askn37]

Currently known issues:

PDI type target devices must provide PDI_CLOCK on the RESET pin. In the host device implementation, this is the USART_XCLK signal. In the AVR-DU family, this is usually only possible on PIN_PA2 and PIN_PA6.

Currently, U4AU uses PIN_PA2 as both UART_TXD (i.e. VCP-TxD) and XCLK, so PDI and VCP are mutually exclusive. Opening VCP to send a character while not in PDI program state will reset the PDI device.

Normally, this issue should be tolerable; PDI control is a bonus.

There are two ways to get around this issue and make PDI and VCP more useful. One is to dedicate PA4+PA6 on U4AU to PDI_DATA/CLK. However, PA6 is one of the few CCL custom output pins. This is not recommended.

Another option is to use external 3-state logic to toggle the signal line and dedicate one GPIO to control the switching of the PDI circuit. This looks promising. Fortunately, PDI control does not require HV control. Having an additional dedicated 6P connector would be nice.

ATxmega AU family VCC voltage:

This PDI type family has a USB peripheral. However, since there is no dedicated VUSB power pin, the VCC voltage must be less than 3.8V for USB to work properly, which is not enough to meet the recommended 4.5V required for the NVM controller. Of course, you can write to the NVM at 3.3V, but you run the risk of a higher error rate.

A serious problem is that operating the device at VCC = 5V may damage the USB port of the host PC. No suitable workaround was found. The best solution is to not enable USB (do not set the pull-up bit) during 5V operation in the ATxmega AU family application code.

All PDI type families appear to have an operating voltage of VCC <= 3.6V or less. At least, this is the case for all Xmega A/AU/B/C/D/E families.

Because of this, the ICSP interface cannot be directly connected to 5V only circuitry such as CNANO which cannot limit the operating voltage to 3.3V.