askn37
commented
1 month ago To support PDI, it needs to run at 3.3V. A voltage supply of 5V will destroy the target silicon.
This problem is serious in nature and is the main reason why the official debugger is not self-powered, but all externally powered. But this is really inconvenient.
Since Curiosity Nano only works at 5V, I have to install an additional 3V3LDO, add a level shifter and a voltage selector switch. As a result, the number of parts needed is three times higher than originally estimated. Plans to sell a cheap kit with board and parts have been cancelled. Only a semi-finished kit with everything populated except for the sockets is a realistic plan. It's a pity that the CNANO doesn't have a 3.3V selector jumper.
We found that 14P chip can also support PDI type, but it needs to support 3.3V at the same time, so we can't simplify the power domain circuit. The only way to save cost is to design a 5V only board without PDI support, or a 3.3V+PDI only board, otherwise we will miss the advantage of 14P.
The HAL profile has been redesigned to allow all AVR-DU families, including 14P, to use ICSP/6P connectors (with VCP functionality) with PDI support.
To achieve this, a 1-gate logic == 3-state buffer is required, and a dedicated control line is used to switch the PDI_CLK output destination.
Similarly, a preliminary design of the HV control expansion board circuitry required for 20P/28P/32P/CNANO has been done, and the GPIOs have been rearranged accordingly. RS232 signal inputs and outputs are no longer included.
Only the CNANO expansion board has FTDI-style DTR/CTS support pins to evaluate the VCP functionality as a generic USB-Serial converter. All other boards only have pure programming tool functionality and two-wire VCP functionality.
Some documentation has been revised in connection with the AVRDUDE 8.0 release.
Additional information
There was confusion about "erase EEPROM page" just before the AVRDUDE 8.0 release, but the provisional code for that has not yet been removed. This issue is still in flux.
By the way, it seems that erasing an EEPROM page can only be properly implemented in AVR-Ex family and PDI type silicon with JTAG interface. (To the extent that this project supports)
In principle, all EEPROMs in the AVR series are based on 1 byte per page, which does not match the definition of an EEPROM page in the standard JTAG commands.
On the contrary, there is no standard JTAG command that corresponds to the AVR series specific memory section erase function. Prior to JTAGmkII, this was done using a mechanism to send extended commands that encapsulated native ISP scripts. (The PICKit5 mechanism took this idea even further)