Wednesday, August 15, 2012

ATxmega programmer for $0.50


A simple interface enables USBASP to program ATxmega16A4 (PDI protocol)

ATxmega programmer for $0.50 or how to make your USBASP support PDI

Do you know XMEGA, the new family of AVR microcontrollers? They look really sweet, especially for someone who already mastered the AVR architecture. More speed (32MHz!), more peripherals (5 USARTs! 16 PWM channels!), modular design, and you can still use the same well known tools. And then you read about the programming interface and... what?! What happened to ISP? No way I would purchase a completely new programmer model just to play with their new MCU!

V-USB interrupt disturbing the PDI clock
 - but not breaking it
Fortunately, implementing the new programming protocol in USBASP was not that hard. Initially I thought it would be almost impossible, because PDI requires a constantly clocking signal and disconnects if the clock rate drops below 10 kHz. Strict timing is a problem for V-USB (USB protocol implementation used in USBASP) as it handles all USB transmissions in software and cannot do both things at the same time (like a guy who lacks brain power to walk and talk at the same time). The tests showed that the interrupt handling a basic control transfer only steals 40-50 us, and this is short enough to allow for the reliable PDI bit banging. Sending more payload (more than a regular control message) would break the clocking but the programmer can be scheduled to work in batches, so it gathers all data from the usb and only then begins the PDI transmission (hoping that there will be no new USB transmission for a while).

Bit-banging clock (to the left)
and timer clock (to the right)
My implementation switches to the hardware timer clocking to keep the clock running during the interrupt-intense USB transmissions. It is not really necessary because the programmer could also disconnect and reconnect after each transmission, but I think the PDI might like the continuous clock better ;-)


Physical connection

If you have a regular USBASP then it is 5V, while the PDI operates at 3,3V. The simple way to reduce the voltage is just adding zener diodes and some resistors. As you can see, SCK becomes PDI DATA and MOSI becomes PDI CLK.
R1 and R2 seem redundant but I put them here after the official Atmel PDI documentation. The thing is, the DATA line is bidirectional and the physical layer should be able to detect collisions. My implementation does not do it, but it could, thanks to the MISO line (maybe someone will implement it some day...). Another weird thing is RESET connection, it looks like it should be GND instead, and yes, this is GND, that can be disconnected at will. Permenent GND connection breaks the PDI bus-keeper so it must be disabled before receiving anything from PDI.
If your USBASP is 3,3V then it would be more simple:

Power supply

If you want to power your circuit from a 5V USBASP then of course you need a 3,3V regulator - but this is not a part of the project.

Software

Obviously, you will need 2 pieces of software:

1. USBASP Firmware supporting PDI


Unpack, apply the patch, compile:


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

...and install in your USBASP


Note: ATmega48 is not supported because its flash area is to small for the increased program size. I only tested it on ATmega8 because that's what in my USBASP. ATmega88 should work, too.

2. AVRDUDE supporting USBASP with PDI

Get the AVRDUDE source and apply the patch against revision 1092:

svn co svn://svn.sv.gnu.org/avrdude/trunk -r 1092
cd trunk/avrdude
patch <full/path/of/usbasp-pdi-avrdude2091-20120816.diff
./bootstrap
./configure
make


./avrdude -C avrdude.conf -c usbasp -p x16a4 -U flash:w:../../../xmega/xmegatest.hex  -E noreset



avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9441
avrdude: NOTE: Programmer supports page erase for Xmega devices.
         Each page will be erased before programming it, but no chip erase is performed.
         To disable page erases, specify the -D option; for a chip-erase, use the -e option.
avrdude: reading input file "../../../xmega/xmegatest.hex"
avrdude: input file ../../../xmega/xmegatest.hex auto detected as Intel Hex
avrdude: writing flash (440 bytes):

Writing | ################################################## | 100% 0.29s

avrdude: 440 bytes of flash written
avrdude: verifying flash memory against ../../../xmega/xmegatest.hex:
avrdude: load data flash data from input file ../../../xmega/xmegatest.hex:
avrdude: input file ../../../xmega/xmegatest.hex auto detected as Intel Hex
avrdude: input file ../../../xmega/xmegatest.hex contains 440 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.27s

avrdude: verifying ...
avrdude: 440 bytes of flash verified

avrdude done.  Thank you.




And the result:
The canonical flashing LED!

What now?

It works for my ATxmega16A4 + Linux but it would be nice to know if it also works on anyone else hardware (especially that the PDI connection reliability depends on the V-USB interrupts). So... download it, test it (and maybe fix it), and if everything goes well, it could be probably included in the official USBASP and AVRDUDE releases.

Summary


  • Add a simple interface to USBASP and you can program ATxmega
  • If you already have USBASP then the interface can be made in minutes almost for free (but if you have to buy USBASP, it is still the least expensive way to program ATxmega)
  • Upgraded USBASP can still program old AVRs (without the interface)
  • There is a catch: you have to install a new firmware in USBASP using another programmer


59 comments:

  1. well it seems I am the first one to comment. Thanks for you wonderful work. I was looking for something like this for past few days. I will try this method and let you know the results.

    ReplyDelete
    Replies
    1. thanks varun!
      if there is no problem please publish your tests results about this here!

      Delete
  2. thank you so much! and I want to appreciate you for your great job! very interesting post!

    ReplyDelete
  3. Hi

    i read this page,your work is very great! but i don't understand your patches! please put new .HEX file and avrdude after manipulate to me and more people can test this way.

    thanks

    ReplyDelete
  4. This what I am looking for my solution, thank for great work

    ReplyDelete
  5. Got it working for an ATXMEGA64D3.
    I just cut and pasted from "# PART DEFINITIONS" to the end from here http://permalink.gmane.org/gmane.comp.hardware.avr.avrdude.devel/3283

    replacing the part definitions in the avrdude.conf. Couldn't substitute the whole thing because the programmer definitions are in an incompatible format.

    Thanks!

    ReplyDelete
  6. This comment has been removed by the author.

    ReplyDelete
  7. I have tried for ATXmega128A1U and ATXmega64A1U and I use avrdude rev 1104 and update for avrdude.conf.
    Hardware photo:
    http://www.facebook.com/photo.php?fbid=443941945647291&set=a.257654870942667.60088.100000944686489&type=1&relevant_count=1&ref=nf


    Unfortunately If I found this error for both

    root@fisika:/home/fisika/sbc# make program
    ./avrdude -p atxmega64a1u -P usb -c usbasp -C avrdude.conf -E noreset -U flash:w:main.hex

    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.02s

    avrdude: Device signature = 0x1e964e
    avrdude: NOTE: Programmer supports page erase for Xmega devices.
    Each page will be erased before programming it, but no chip erase is performed.
    To disable page erases, specify the -D option; for a chip-erase, use the -e option.
    avrdude: reading input file "main.hex"
    avrdude: input file main.hex auto detected as Intel Hex
    avrdude: writing flash (598 bytes):

    Writing | ################################################## | 100% 0.47s

    avrdude: 598 bytes of flash written
    avrdude: verifying flash memory against main.hex:
    avrdude: load data flash data from input file main.hex:
    avrdude: input file main.hex auto detected as Intel Hex
    avrdude: input file main.hex contains 598 bytes
    avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 0.54s

    avrdude: verifying ...
    avrdude: verification error, first mismatch at byte 0x0100
    0xff != 0x0c
    avrdude: verification error; content mismatch

    avrdude done. Thank you.



    I hope someone can solve this problem for ATXmega128A1U and ATXmega64A1U.

    my email: wandiufo@gmail.com

    ReplyDelete
    Replies
    1. first thing that comes to my mind would be checking if the parameters inside avrdude.conf file match the atmel datasheet for those chips, especially the "page_size" value.

      where did you get the xmega128/64a1u update? rev 1104 avrdude.conf does not have them.

      Delete
  8. This comment has been removed by the author.

    ReplyDelete
  9. This comment has been removed by the author.

    ReplyDelete
  10. THANK, I SUCCESS FOR BOTH

    I am happy :)
    I just completed successfully for test blink LED for ATXmega128A1U and ATXmega64A1U after following your suggestion for update the page_size

    for x128a1u use page_size=0x200
    for x64a1u use page_size=0x100
    except for eeprom 0x20
    (info from the datasheet)
    but the signature still use from parent can't use from datasheet. why ? I hope your comment!

    detail
    http://www.facebook.com/download/368019266616585/avrdude.conf.success

    Finally thank for your work and I hope to be official at usbasp and avrdude.

    Best regards,
    Irwandi

    ReplyDelete
    Replies
    1. great! i'm glad my interface works for you :-)

      as for the signature, i think the avrdude somehow reads the correct signature from your conf file, otherwise it would stop with error message, telling that the signature does not match the chip. so, everything seems okay.

      Delete
  11. Hi, I sucessfuly moved this onto an atmega16 which I had, everything works fine, but when I try to program atxmega128a3u, I get this error message:
    d:\Work\!electro\bp\!xmegatest>avrdude -c usbasp -p x128a3
    avrdude: AVR device initialized and ready to accept instructions
    Reading | | 0% 0.00savr_read(
    ): error reading address 0x0000
    read operation not supported for memory "signature"
    avrdude: error reading signature data for part "ATxmega128A3", rc=-2
    avrdude: error reading signature data, rc=-1
    avrdude done. Thank you.

    Any thoughts what could be the problem?

    ReplyDelete
    Replies
    1. you mean, you used atmega16 instead of atmega8 in usbasp?

      at first i thought it can't work, because unlike atmega8, the atmega16's MOSI does not have OC2 output (that is crucial for PDI_CLK function in this project). but actually, if you are building your own programmer and not just connecting to an existing USBASP then you could have adjusted for this and used atmega16's PD7/OC2 for PDI_CLK instead of MOSI.

      the avrdude behavior is also consistent with the missing PDI_CLK timer hypothesis... it connects at first but then, after a second usb transaction, the pdi connection is gone.

      so, what atmega pin do you use for PDI_CLK?

      Delete
  12. I used mosi for the clock pin. When I connect it to PD7/OC2, then the programmer says initialization faild even before it gets to signature.
    It seems that you setup the timer2, but don´t use it anywhere. Which mode should I use for the OC2 pin? Toggle OC2 on compare match?

    ReplyDelete
    Replies
    1. well, of course you would have to change the relevant PORT and DDR assignments when using PD7 instead of PB3 (functions: pdiInit, pdiCleanup, pdiSetClk1/0).

      the timer is certainly being used, otherwise the whole thing would not work ;-) see pdiEnableTimerClock and pdiDisableTimerClock.

      from what i see in the source, it works with no prescaling, CTC mode (OCR2=32), toggle OC2 on compare match.

      Delete
  13. I am a Japanese.

    It was interested in created USBasp (PDI function).
    It is a very wonderful result.

    Then, write-in environment to ATXmega was realized
    in the Windows environment.
    Operation by ATmega88 is also checked.

    Development progress is written to the following URL.

    http://www-ice.yamagata-cit.ac.jp/forum/viewtopic.php?t=970

    Although it all is Japan, please use translation software and check it.

    ReplyDelete
    Replies
    1. thank you for sharing your success story! i have briefly browsed the threads on the forum and it seems very informative for anyone wanting to troubleshoot the usbasp-pdi interface. too bad, the automated translation is so crude...

      btw. did you know the forum is rejecting access for anyone outside of japan? i had to use japanese web proxy to read it, otherwise i can only see "http error 403 - forbidden".

      Delete
  14. Unjust posting on a bulletin board continued and it
    forbade access from other than Japan now.

    Although I feel sorry very much, please access using a http proxy.

    In addition, there is indication that the processing speed of
    USBasp (PDI support) is slow.

    What kind of method can be considered for this improvement?

    ReplyDelete
    Replies
    1. actually, i haven't yet used usbasp/pdi for any serious work, which means i only uploaded really small programs and the speed was irrelevant :-)
      usbasp's atmega8 won't be able to match the performance of the "true" pdi programmer (which implements usb and pdi in hardware rather than software), but definitely, some improvements are possible.
      first you could increase the pdi clock speed (decrease the delay in pdiWaitBit function), then maybe force inlining of the most commonly called functions (pdiSetClk0/pdiSetClk1/pdiSetData...etc...), or change them into #define's.

      Delete
  15. Thank you for the advice.

    When the inline substitution of the pdi-related function
    was carried out, about 20% of time crunch was completed.

    Since it is not the result of still wishing, I improve.

    ReplyDelete
  16. Thanks to your Job
    i have a problem with atxmega128a1
    Signature cheak is fine but program flash failed:
    sudo ./avrdude -C avrdude.conf -c usbasp -p x128a1

    avrdude: AVR device initialized and ready to accept instructions
    Reading | ################################################## | 100% 0.03s
    avrdude: Device signature = 0x1e974c
    avrdude done. Thank you.

    =>
    ./avrdude -C avrdude.conf -c usbasp -p x128a1 -U flash:w:../../proj.hex -E noreset

    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.03s

    avrdude: Device signature = 0x1e974c
    avrdude: NOTE: Programmer supports page erase for Xmega devices.
    Each page will be erased before programming it, but no chip erase is performed.
    To disable page erases, specify the -D option; for a chip-erase, use the -e option.
    avrdude: reading input file "../../proj.hex"
    avrdude: input file ../../proj.hex auto detected as Intel Hex
    avrdude: writing flash (1432 bytes):

    Writing | ################################################## | 100% 1.53s

    avrdude: 1432 bytes of flash written
    avrdude: verifying flash memory against ../../proj.hex:
    avrdude: load data flash data from input file ../../proj.hex:
    avrdude: input file ../../proj.hex auto detected as Intel Hex
    avrdude: input file ../../proj.hex contains 1432 bytes
    avrdude: reading on-chip flash data:

    Reading | | 0% 0.00savrdude: paged_load failed
    avr_read(): error reading address 0x0000
    read operation not supported for memory "flash"
    avrdude: failed to read all of flash memory, rc=-2

    avrdude done. Thank you.

    page_size in avrdude.conf is 0x200 for xmega128a1

    ReplyDelete
    Replies
    1. looks like it works for a while but then loses the connection before reading flash... i wonder what would happen if you tried just reading instead of writing?

      ./avrdude -C avrdude.conf -c usbasp -p x128a1 -U flash:r:/tmp/readtest.hex -E noreset

      i assume you tried several times with the same result so we can be sure the culprit is not of "electrical" matter? (like, too long cables catching noise)

      Delete
    2. ./avrdude -C avrdude.conf -c usbasp -p x128a1 -U flash:r:/tmp/readtest.hex -E noreset

      avrdude: AVR device initialized and ready to accept instructions

      Reading | ################################################## | 100% 0.03s

      avrdude: Device signature = 0x1e974c
      avrdude: NOTE: Programmer supports page erase for Xmega devices.
      Each page will be erased before programming it, but no chip erase is performed.
      To disable page erases, specify the -D option; for a chip-erase, use the -e option.
      avrdude: reading flash memory:

      Reading | | 0% 0.00savrdude: paged_load failed
      avr_read(): error reading address 0x0000
      read operation not supported for memory "flash"
      avrdude: failed to read all of flash memory, rc=-2

      avrdude done. Thank you.

      i tested it about 10 times and the result is almost same.
      i used circuit number one for 5volt MEGA8 USBASP .

      Delete
    3. I encountered a similar problem, using a 64 bit Acer aspire laptop, instead of my 32 bit desktops or laptop. (they all work fine) I tried re-compiling avrdude in the 64 bit environment, same result. The write operation goes 2x as fast, then the read fails.

      Delete
    4. If anybody has it working on a 64 bit machine, I'd like to hear about it :) --Karl

      Delete
    5. so, the only difference is 32 bit vs. 64 bit - very interesting test case! (i'm sorry for calling it "interesting", when for you it is only "annoying").

      assuming the avrdude and libusb work exactly the same (why they should not?), the difference must be somewhere in the windows usb subsystem. maybe the usb polling rate is different in 64 bit windows? i know it can be adjusted somehow and some people like to increase it to optimize the usb mouse responsiveness. changing this parameter wont harm a "normal" usb device, but my usbasp's PDI extension will fail if a new usb activity begins before the previous PDI operation was finished. (this is because unlike ISP, the PDI wont automatically pause/resume when the host stops sending a clock signal, and usbasp handles all usb activity in software so it has to interrupt everything else when something happens on the usb bus).

      so maybe if you tried tweaking the usb polling rate...? this is all assuming your 64 bit windows can handle the normal usbasp ISP programming correctly so we know the problem is PDI-specific.

      Delete
    6. No, not annoyed. I thank you so much for sharing your work!

      I forgot to mention: Op Sys is Puppy Linux V. Lupu, not windows.

      Either way, "PDI extension will fail if a new usb activity begins before the previous PDI operation was finished." seems to me to fit what I see.

      Can the usb polling rate be adjusted in the source of Avrdude? Or is that a lower level thing? Re compile the hid kernel driver?

      I glanced at hid-core.c and it has a section:

      /* Change the polling interval of mice. */
      if (hid->collection->usage == HID_GD_MOUSE && hid_mousepoll_interval > 0)
      interval = hid_mousepoll_interval;

      But that only works for usage = HID_GD_MOUSE. What is the usage of a USBASP?

      I'm OK with just 32 bit machines for now, but basically they are obsolete, Can you even buy a new 32bit x86 machine any more? --Karl

      Delete
    7. aaaah, so that's linux! then perhaps i will be able to test this case by running some 64-bit live CD or something. my guess about the usb polling rate may be of course completely wrong, it is just the only thing i could find that could be different between systems. in linux, the default value is probably the same in both 32 and 64 bit.

      Delete
  17. i'm from indonesia
    i have usbasp with atmega8 as chip, then i used that download my hex program to AVR Atmega 8535 but i found problem like this
    Reading |
    Reading | ################################################## | 100% 0.50s

    avrdude.exe: verifying ...
    avrdude.exe: verification error, first mismatch at byte 0x0000
    0x32 != 0x00
    avrdude.exe: verification error; content mismatch

    avrdude.exe done. Thank you.

    please give me any solution for that.thnks

    ReplyDelete
    Replies
    1. This block focus on new xmega with PDI interface.

      Delete
  18. Great idea, I like to try this feature!

    Is there anyone can send me the HEX & revised avrdude.exe files?
    (I don't know how to make it)

    Thanks in advance!!!

    mengjins@hotmail.com

    ReplyDelete
  19. Dear All,
    i built programmer by this guide, but it's not working :-(

    i'm using command:
    ./avrdude -C avrdude.conf -c usbasp -p x192a3 -U fuse1:r:fuse1.txt:i -E noreset

    after each run i'm getting back different signatures ,
    for example:
    avrdude: Device signature = 0x0e97e0
    avrdude: Device signature = 0x1e9720
    avrdude: Device signature = 0x0e9744
    Expected signature for ATxmega192A3 is 1E 97 44

    please help me ...

    kind regards,

    ReplyDelete
    Replies
    1. found it ... missing capacitor on power supply ... sorry for disturbing ...

      Delete
  20. Hello!
    I can't get it work. I'm using a ATmega168PA as usbasp which is working fine for ATmega/tiny etc. but not with ATxmega :(
    Does anybody have an idea?


    ./avrdude -p atxmega128a4 -P usb -c usbasp -C ../etc/avrdude.conf -U flash:r:/tmp/readtest.hex -E noreset

    avrdude: initialization failed, rc=-1
    Double check connections and try again, or use -F to override
    this check.


    avrdude done. Thank you.

    ReplyDelete
    Replies
    1. Now I got this... but only once

      ./avrdude -p atxmega128a4 -P usb -c usbasp -C ../etc/avrdude.conf -U flash:r:/tmp/readtest.hex -E noreset

      avrdude: AVR device initialized and ready to accept instructions

      Reading | | 0% 0.00savr_read(): error reading address 0x0000
      read operation not supported for memory "signature"
      avrdude: error reading signature data for part "ATxmega128A4", rc=-2
      avrdude: error reading signature data, rc=-1

      avrdude done. Thank you.

      Delete
    2. Today I tried to compile it on 32-bit Debian and 32-bit Mac OS X.
      On Mac OS I get the error above, on Debian:


      ./avrdude -C avrdude.conf -c usbasp -p x128a4 -U flash:r:../../test.hex -E noreset -F

      avrdude: initialization failed, rc=-1
      avrdude: AVR device initialized and ready to accept instructions
      avrdude: Device signature = 0xd8d376
      avrdude: Expected signature for ATxmega128A4 is 1E 97 46
      avrdude: NOTE: Programmer supports page erase for Xmega devices.
      Each page will be erased before programming it, but no chip erase is performed.
      To disable page erases, specify the -D option; for a chip-erase, use the -e option.

      avrdude done. Thank you.

      Delete
    3. This may not help, just a suggestion: the usbasp needs to be programmed with the patched firmware. I have only used a usbasp with atmega8, and the above patch. Should work with a 8 and an 88. Not sure it will work on a atmega168 usbasp? --Karl

      Delete
    4. I already programmed the patched fw on the usbasp. If 88 works, 168 should also work.

      Delete
  21. Hello
    I've got problem
    When i use avrdude i'm getting back random signatures
    i used 100nF on supply butthen i've got
    avrdude: initialization failed, rc=-1

    any idea?

    ReplyDelete
    Replies
    1. Same problem here :(

      Delete
    2. I started reading Jan Axelson's "USB Complete" It occurs to me that Vusb has to look at all traffic on the USBus for the correct address. I'm not sure about that, but it might be worth trying the USBAsp on a PC side controller with out anything else connected to it. Not not that a PC with no keyboard, not mouse, no camera, no wifi is very useful, but it might clear up what's going on here.

      Delete
  22. This comment has been removed by the author.

    ReplyDelete
  23. Problem with ATxmega128a1. I can program ATxmega32A4 Successfully but for ATxmega128A1 : (page_size = 0x200)


    avrdude.exe: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.02s

    avrdude.exe: Device signature = 0x1e974c
    avrdude.exe: erasing chip
    avrdude.exe: reading input file "E:\My Projects\QuadRotors\Second QuadCopter\Programing\Main Board\Codevision AVR XMEGA\Xaircraft Softwares\(2) IMU+RC+MOTOR+PID\Exe\IMU+RC+MOTOR+PID.hex"
    avrdude.exe: input file E:\My Projects\QuadRotors\Second QuadCopter\Programing\Main Board\Codevision AVR XMEGA\Xaircraft Softwares\(2) IMU+RC+MOTOR+PID\Exe\IMU+RC+MOTOR+PID.hex auto detected as Intel Hex
    avrdude.exe: writing flash (20250 bytes):

    Writing | ################################################## | 100% 7.28s

    avrdude.exe: 20250 bytes of flash written
    avrdude.exe: verifying flash memory against E:\My Projects\QuadRotors\Second QuadCopter\Programing\Main Board\Codevision AVR XMEGA\Xaircraft Softwares\(2) IMU+RC+MOTOR+PID\Exe\IMU+RC+MOTOR+PID.hex:
    avrdude.exe: load data flash data from input file E:\My Projects\QuadRotors\Second QuadCopter\Programing\Main Board\Codevision AVR XMEGA\Xaircraft Softwares\(2) IMU+RC+MOTOR+PID\Exe\IMU+RC+MOTOR+PID.hex:
    avrdude.exe: input file E:\My Projects\QuadRotors\Second QuadCopter\Programing\Main Board\Codevision AVR XMEGA\Xaircraft Softwares\(2) IMU+RC+MOTOR+PID\Exe\IMU+RC+MOTOR+PID.hex auto detected as Intel Hex
    avrdude.exe: input file E:\My Projects\QuadRotors\Second QuadCopter\Programing\Main Board\Codevision AVR XMEGA\Xaircraft Softwares\(2) IMU+RC+MOTOR+PID\Exe\IMU+RC+MOTOR+PID.hex contains 20250 bytes
    avrdude.exe: reading on-chip flash data:

    Reading | ################################################## | 100% 10.73s

    avrdude.exe: verifying ...
    avrdude.exe: verification error, first mismatch at byte 0x0000
    0xff != 0x0c
    avrdude.exe: verification error; content mismatch

    avrdude.exe done. Thank you.

    ReplyDelete
    Replies
    1. I still need your help!!!
      I've written and Verified EEPROM and it works but Flash does not work.

      avrdude.conf :

      #------------------------------------------------------------
      # ATxmega128A1
      #------------------------------------------------------------

      part parent ".xmega"
      id = "x128a1";
      desc = "ATxmega128A1";
      signature = 0x1e 0x97 0x4c;

      memory "eeprom"
      size = 0x0800;
      offset = 0x08c0000;
      page_size = 0x20;
      readsize = 0x100;
      ;

      memory "application"
      size = 0x00020000;
      offset = 0x0800000;
      page_size = 0x200;
      readsize = 0x100;
      ;

      memory "apptable"
      size = 0x00002000;
      offset = 0x0081e000;
      page_size = 0x200;
      readsize = 0x100;
      ;

      memory "boot"
      size = 0x00002000;
      offset = 0x00820000;
      page_size = 0x200;
      readsize = 0x100;
      ;

      memory "flash"
      size = 0x00022000;
      offset = 0x0800000;
      page_size = 0x200;
      readsize = 0x100;
      ;

      memory "fuse0"
      size = 1;
      offset = 0x8f0020;
      ;

      memory "fuse1"
      size = 1;
      offset = 0x8f0021;
      ;

      memory "fuse2"
      size = 1;
      offset = 0x8f0022;
      ;

      memory "fuse4"
      size = 1;
      offset = 0x8f0024;
      ;

      memory "fuse5"
      size = 1;
      offset = 0x8f0025;
      ;

      memory "lock"
      size = 1;
      offset = 0x8f0027;
      ;
      ;

      Delete
    2. Hi Senshu

      i can't open your site forum. i have a proxy with 5 server but i can't do it.
      is it possible upload your file on the other server?

      Delete
  24. This comment has been removed by the author.

    ReplyDelete
  25. how about is progress for merge to avrdude and usbasp official development?
    If usbasp is not to merge it, you can make your own firmware like usbasp2 but not for avrdude. I hope avrdude should be support officially.

    ReplyDelete
  26. Thank you for your solution szu!
    I am exactly at the same point that you have described here so nice.
    Everywhere you will only find a discussion which programmer to buy and that it is the best to buy the "original" from Atmel for $xxx. ;-)
    But you have find the optimum opensource solution for the problem.

    There is a problem to compile the usbasp now.
    It is described with a solution here: http://forums.obdev.at/viewtopic.php?f=8&t=6424

    I mastered it and packed the whole modified source packages with precompiled binaries now, so everyone can use them or compile them easy again.
    You can download it here: http://decotrain.de/public/PDI-programmer.tgz

    Has anyone contacted the supplier of avrdude and usbasp?
    I will write them, because this solution should be implemented regulary.

    ReplyDelete
  27. Hi, tryed so many things but can't program any bootloader on a xmega, allways fails on verify like this:

    avrdude: verifying ...
    avrdude: verification error, first mismatch at byte 0x0000
    0xff != 0x0c
    avrdude: verification error; content mismatch

    ReplyDelete
    Replies
    1. First, many thanks to Szu for his wonderful work.

      I have used the PDI mods to program x128d3 and 192a3u with no problems. However I could not program the flash memory on a x128a1.

      I could program eeprom Ok so I thought the chip must be OK and I Googled for many days without finding anything relevant. The I found in the 'Errata' section of the x128a1 manual that certain NVM commands do not work, namely ERASE_FLASH and WRITE_FLASH! Atmel say to use write and erase application section instead. There is an easy way to fix this but I am sure it could be done more elegantly, also these mods work with the 128a1 but have not been checked for other devices. Apply the patch file to avrdude and then find xmega_pdi.h in the avrdude source. Lines 41,42,43 contain the definitions of the NVM commands which DONT work on the x128a1, change 0x2B, 0x2E and 0x2F to 0x22, 0x24 and 0x25 on their respective lines. This gets avrdude to send the appsection commands instead of the generic flash commands so you will not be able to get at the whole of the flash memory if you have a very large application. In particular you probably won't be able to program a bootloader but for that purpose you could change the modified codes to 2A, 2C and 2D which should load a bootloader but not the rest of the application memory.

      I kept the modified version as avrdude128 and only use it to program the x128a1.

      This is not yet thoroughly tested but I will post again if I find any serious problems.

      Delete
  28. Hi Szu,
    I finally managed to make it work for me.
    It was little bit tricky because I used atmega16 @16MHz for USBASP. From beginning I wanted programmer for both tiny/mega (ISP) and xmega (PDI) so I combined both USBASP and your extension.
    Now I can confirm it works without removal of the PDI extension part on one PCB.

    Hardest part for me was avrdude build from sources. For Windows 7 64-bit. It took three days to successfully get avrdude.exe from MinGW. Problem was my gnu-gcc compilation skills.
    USBASP firmware build was easier but your direct port pin numbers usage in pdi.c made it little bit interesting :-)
    Especially because I have CLK/RESET/DATA pins on two different ports (B and D).

    Anyway I have one problem.
    After USBASP connection to USB and after xmega programming the CLK pin (RESET) is low. It means the xmega is kept in reset.
    I am going to update firmware to fix it but I do not fully understand your timer usage in pdi part.

    Your code uses HW clock generation (OC2) and also program logic that changes clock levels programatically.
    Please confirm these two approaches are not mixed. I see that HW clock generation is controlled in main.c but I do not fully understand program flow yet.

    One more comment: I see small typo in pdi.c. Search for (0<CS21).
    I should by (0<<CS21)
    Also comment next to timer setup (12MHz/256) is little bit confusing because timer clock does not use prescaler.

    Best regards,
    Rado

    ReplyDelete
    Replies
    1. Ok, I solved both the issues.
      Original USBASP firmware sets port D as output with out level = low. In my case (atmega16) MOSI/CLK is connected to PD7. Call to ispDisconnect() in main solved reset after powerup.
      Reset after programming can be configured in avrdude by option -E.

      Regards
      Rado

      Delete
  29. Can anybody apply the path for PDI programming to newer avrdude (avrdude-6.0rc1 - from: http://download.savannah.gnu.org/releases/avrdude/)?

    Here is a nice GUI with fusecalculator: http://www.avr-elektronika.tk/index.php?page=pdi-programmer

    regards
    joyc

    ReplyDelete
  30. Hello,
    I cannot get the connections of the circuit used. How can a clock pin, SCK of USBasp be connected to PDI_data? How can MOSI be providing clock?

    ReplyDelete