usbasp xmega pdi enhancement

[mcuee]

From here http://szulat.blogspot.com/2012/08/atxmega-programmer-for-050.html and here: https://ketturi.kapsi.fi/2013/05/programming-xmega-with-usbasp-avrdude/

There are patched usbasp FW and patched avrdude version to support PDI using usbasp (arguably the most popular DIY USB AVR programmer).

It would be good to integrate the patch in avrdude.

[mcuee]

usbasp firmware patch from the first link: usbasp-pdi-usbaspfirmware-20120816.diff.txt

tar xvzf usbasp.2011-05-28.tar.gz
cd usbasp.2011-05-28/firmware
patch <full/path/of/usbasp-pdi-usbaspfirmware-20120816.diff
make main.hex

avrdude patch from the first link: usbasp-pdi-avrdude2091-20120816.diff.txt

usbasp firmware hex build from the second link (only for ATmega8) usbasp-pdi-patch.zip

avrdude mingw32 build from the second link (only for reference as it is using quite an old version of avrdude). avrdude-usbasp-pdi-bin.zip

[mcuee]

usbasp patched firmware with hex files for ATmeag8/48/88 https://github.com/nieldk/USBASP-PDI

Associated avrdude 6.3 patches for the above. https://github.com/nieldk/avrdude

Modified usbasp HW -- FabPDI, ATmega8 FW image and patched avrdude-6.3 Windows binary https://github.com/skeatz/FabPDI (includes ATmega8 based usbasp pdi programmer, and AT90USB162 based AVRISP mkii clone). https://github.com/skeatz/FabPDI/tree/master/files/fabpdi-mega8

[mcuee]

@dioannidis

I am not so sure if you are interested to integrate the improvement to your usbasp repo.

[dioannidis]

@mcuee

I am not so sure if you are interested to integrate the improvement to your usbasp repo.

I don't have a xmega avr but I'll order this week some atxmega16e5-au and I'll give it a try .

[MCUdude]

I don't have a xmega avr but I'll order this week some atxmega16e5-au and I'll give it a try .

Awesome! It makes much more sense to try to add USBasp Xmega support to Avrdude if there is up-to-date USBasp firmware that can easily be flashed to existing hardware. And the little hardware that the USBasp requires to deal with the PDI interface is something that could easily be made and sold online, on Tindie for instance.

[dioannidis]

@MCUdude

OT: The IC's ( I ordered 3 atxmega16e5 tqfp32 ) arrived yesterday but I cannot make them to work .... I soldered them to smt breakout pcb's, checked all the connections but my mplab snap cannot communicate with them ( using either Studio 7, MPLAB X IDE or avrdude ) . I read the mplab snap pinout for PDI from here https://onlinedocs.microchip.com/pr/GUID-CE8CBDF8-D51B-4BC5-8EF8-F01B7427113D-en-US-4/index.html?GUID-A03031A3-B98D-4579-BE3C-399B78B72D3A .

Do you have any minimal setup for atxmega16e5 in case I missed something ?

[MCUdude]

I haven't designed anything around an xmega before, so I don't have any known good reference designs. However, this website sells an ATxmega32e5 breakout board where they have the schematic in their user manual:

https://botland.store/withdrawn-products/2839-xmega-exploree5-with-atxmega32e5-mod-26.html

[mcuee]

This one is another breakout board schematics. https://morf.lv/playing-with-atxmega16e5-breakout

[mcuee]

Personally I got the breakout board from MCUZone. The boards are also available from AliExpress. https://wildchip.aliexpress.com/store/group/ATXMEGA-AVR32-mini-Board/5881453_517582356.html

[dioannidis]

@mcuee

AFAIU, you have an MPLAB SNAP programmer. If so, is it possible to check if you can program your breakout board with it ?

[mcuee]

@mcuee

AFAIU, you have an MPLAB SNAP programmer. If so, is it possible to check if you can program your breakout board with it ?

So far I use AVRISP mkii for the ATxmega breakout board. I will try SNAP tomorrow.

[dioannidis]

@mcudude, @mcuee

Thx for the schematics . It seems that I didn't miss something reg. connections for the atxmega16e5 .

[mcuee]

@dioannidis

If you have some boards based on ATmega32U4 (like Arduino Leonardo), you can build your own AVRISP mkII with the board.

Example: https://github.com/elfmimi/ProMicro-AVRISP-mkII https://www.fourwalledcubicle.com/AVRISP.php https://github.com/abcminiuser/lufa/tree/master/Projects/AVRISP-MKII

[dioannidis]

@MCUdude , @mcuee

FYI, I've been bitten from "Symptom: Programming and debugging fails with AVR microcontroller devices that use the UPDI/PDI/TPI interfaces. MPLAB SNAP, Assembly #02-10381-R1 requires an external pull-up resistor for AVR microcontroller devices that use these interfaces".

Simple adding a pull-up 1K resistor to PGD pin ( PDI data ) fixed my SNAP issue . From MPLAB® SNAP AVR UPDI/PDI/TPI Interface Modification.

[mcuee]

@dioannidis

Glad that your sorted out the issue. I had the same issue when I first tried SNAP.

[SpenceKonde]

Huh! I wonder if that's why I could never make my SNAPs work.

[MCUdude]

Huh! I wonder if that's why I could never make my SNAPs work.

Very likely! I had to modify mine

[mcuee]

Huh! I wonder if that's why I could never make my SNAPs work.

Very likely! I had to modify mine

Same here, I had to modify mine as well.

[dioannidis]

Huh! I wonder if that's why I could never make my SNAPs work.

Very likely! I had to modify mine

I just made an adapter with an 1K resistor and a jumper ...

[MCUdude]

@dioannidis did you have time to look into this? It would be really cool to have the USBasp support Xmega programming!

[dioannidis]

@MCUdude Resumed working on it yesterday ( came back from vacation a few days ago .... )

[dioannidis]

@MCUdude , @mcuee

A very early USBasp with PDI support ( using szu's from http://szulat.blogspot.com/ code ) is at https://github.com/dioannidis/usbasp/tree/pdi_support branch

Use make PDI=1 main.hex to build it. ( see commit https://github.com/dioannidis/usbasp/commit/e944dd44fff830f0216ca167ea09895dca2ed4e3 )

[MCUdude]

Great work! But does this means that you can't have ISP, TPI and PDI support at the same time? For me personally, this is more important than a support for a virtual serial port.

BTW do you have an Avrdude fork where you've applied the USBasp PDI patch as well? I can use to test?

[dioannidis]

@MCUdude , @mcuee

I'm using the avrdude mingw32 from post https://github.com/avrdudes/avrdude/issues/1024#issuecomment-1181198670 for preliminary tests

[dioannidis]

@MCUdude

Great work! But does this means that you can't have ISP, TPI and PDI support at the same time?

You can use TPI, PDI and HIDUART/SerialWrite at the same time . i.e. make TPI=1 PDI=1 HIDUART=1 main.hex

Also, if you don't specify HIDUART then the firmware is not a composite device . It's a WCID WINUSB device with MS 2.0 Descriptors ...

[dioannidis]

@MCUdude

BTW do you have an Avrdude fork where you've applied the USBasp PDI patch as well? I can use to test?

You can find a very early manually patched non working avrdude main at https://github.com/dioannidis/avrdude/tree/pdi_support branch.

[dioannidis]

Hi,

@MCUdude , @mcuee

after a few days fiddling with the firmware code, I assume that the ( relative new ... ) ATxmega16e5 I'm using, is not so forgiving with the hand crafted not stable clock and/or timing of this patches, as maybe older ATxmega is. I tried all the FW's from above ( and some others...) , the patched 6.3 avrdude and my patched main avrdude ( and various combination ) but no success ....

As I don't have any other ATxmega, I decided to not spend any more time debugging and trying to fix the patch('s) and rewrite the PDI communication part using SPI .

FYI

/* From V-USB usbdrv.h

Interrupt latency:
The application must ensure that the USB interrupt is not disabled for more
than 25 cycles (this is for 12 MHz, faster clocks allow longer latency).
This implies that all interrupt routines must either have the "ISR_NOBLOCK"
attribute set (see "avr/interrupt.h") or be written in assembler with "sei"
as the first instruction.

Maximum interrupt duration / CPU cycle consumption:
The driver handles all USB communication during the interrupt service
routine. The routine will not return before an entire USB message is received
and the reply is sent. This may be up to ca. 1200 cycles @ 12 MHz (= 100us) if
the host conforms to the standard. The driver will consume CPU cycles for all
USB messages, even if they address another (low-speed) device on the same bus.

*/

/* From Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf

32.3.2 Disabling
If the clock frequency on PDI_CLK is lower than approximately 10kHz, 
this is regarded as inactivity on the clock line. This will automatically disable the PDI. 
If not disabled by a fuse, the reset function of the Reset (PDI_CLK) pin is enabled again.
 This also means that the minimum programming frequency is approximately 10kHz

*/

regards,

[dioannidis]

Hi,

@MCUdude , @mcuee

AFAIU, the only way to connect SPI's MOSI and MISO together for PDI communication, is to tri-state the pins and enable them when they're needed ( Tx - MOSI, Rx - MISO ), as the PDI_DATA pin has an internal pull resistor when PDI physical is enabled.

When the SPI is enabled in Master Mode, the input pin (MISO) is automatically configured, and, AFAIU, the only way to tri-state it, during SPI transmision ( which is happens all the time, for clock generation and sync purposes), is to use a buffer for provide HiZ ( i.e. one port of a 74HCT125N ).

FYI, I succeeded to implement transmit and receive PDI messages using SPI ( abusing it a lot ....;) ) see: https://github.com/dioannidis/usbasp/tree/pdi_support, but it was more difficult than I anticipated ( for me anyway ... ). This was one of the reasons that it took me so long to reach at this point ( not too much free time is another one ... ).

I'll start to add the missing functionality, now that the Tx/Rx part is finished ( need more testing ... ), so I would like to ask if there is still interest for this .

... And the little hardware that the USBasp requires to deal with the PDI interface is something that could easily be made and sold online, on Tindie for instance.

The add-on hardware needed for my implementation needs a buffer to provide high input impendence for MISO and two current limiting resistors . Do you think that will be a problem ?

regards,

[dioannidis]

Hi,

hmm, no response. Anyway, I'll continue working to finish this.

Using the following circuit, I can read the signature of the ATXmega16E5 using avrdude ( https://github.com/dioannidis/avrdude/tree/pdi_support ) and usbasp ( https://github.com/dioannidis/usbasp/tree/pdi_support ) ;) .

C:\Users\thouli>G:\Programming\dimitris\tools\avrdude_github\out\build\x64-Debug\src\avrdude.exe -C G:\Programming\dimitris\tools\avrdude_github\out\build\x64-Debug\src\avrdude.conf -c usbasp -p x16e5 -vv

avrdude: Version 7.2-20230920 (67f8a144)
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

         System wide configuration file is G:\Programming\dimitris\tools\avrdude_github\out\build\x64-Debug\src\avrdude.conf

         Using Port                    : usb
         Using Programmer              : usbasp
avrdude:[set_debug] setting debugging level to 255 (on)
avrdude:[os_find_busses] found bus-0
avrdude:[os_find_devices] found \\?\usb#vid_16c0&pid_05dc#0000#{a5dcbf10-6530-11d2-901f-00c04fb951ed}--WINUSB on bus-0
avrdude: seen device from vendor >www.fischl.de<
avrdude: seen product >USBasp<
         AVR Part                      : ATxmega16E5
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         Serial program mode           : yes
         Parallel program mode         : yes
         Memory Detail                 :

                                           Block Poll               Page                       Polled
           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuse1                   0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuse2                   0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuse4                   0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuse5                   0     0     0    0 no          1    1      0     0     0 0x00 0x00
           lock                    0     0     0    0 no          1    1      0     0     0 0x00 0x00
           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
           prodsig                 0     0     0    0 no         50   50      0     0     0 0x00 0x00
           data                    0     0     0    0 no          0    1      0     0     0 0x00 0x00
           io                      0     0     0    0 no       4096    1      0     0     0 0x00 0x00
           fuse6                   0     0     0    0 no          1    1      0     0     0 0x00 0x00
           eeprom                  0     0     0    0 no        512   32      0     0     0 0x00 0x00
           flash                   0     0     0    0 no      20480  128      0     0     0 0x00 0x00
           application             0     0     0    0 no      16384  128      0     0     0 0x00 0x00
           apptable                0     0     0    0 no       4096  128      0     0     0 0x00 0x00
           boot                    0     0     0    0 no       4096  128      0     0     0 0x00 0x00
           usersig                 0     0     0    0 no        128  128      0     0     0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp ISP, TPI and PDI programmer
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02 s
avrdude: device signature = 0x1e9445 (probably x16e5)

avrdude done.  Thank you.

regards,

[MCUdude]

@dioannidis sorry for not responding! I've been busy, but that's no excuse. I'll see if I can re-flash my USBasp and see if I can get it working this weekend.

[mcuee]

@dioannidis Sorry but it seems to me I do not have the right HW to test now. Hopefully @MCUdude can carry out the test.

[mcuee]

sorry for not responding! I've been busy, but that's no excuse. I'll see if I can re-flash my USBasp and see if I can get it working this weekend.

@MCUdude

Just wondering if you have any updates here. Thanks.

[mcuee]

@dioannidis

It seems to me that you are saying HW modification is needed to use USBASP with xmega parts, right?

Have you been able to program PDI xmega part in the end, other than reading the signature?

[dioannidis]

@mcuee

Apologies for the late response ( day work and family life sometimes happens and totally missed this comment ) . I was waiting for @MCUdude to do some test and unfortunately I forgot about it and didn't finished it . To answer your questions, I didn't test anything else except reading the signature :( ( with HW modification or not ) ...

I'll take a look again ...