AVRDUDE PDI programming

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anyone been programming XMEGAs with avrdude and the AVRISPmkII or JTAGICEmkII using PDI? Mine will not read the device signature for some reason. It will program fine if I use -F to skip the signature check. Anyone have a fix? By the way, I'm using the latest avrdude 5.8 from SVN on Fedora Linux.

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't been able to program the fuse bytes either:

avrdude -v -v -F -Pusb -cavrispmkii -px16a4 -Ufuse0:w:0xde:m

for example fails with:

Quote:
avrdude: Version 5.8cvs, compiled on Nov 10 2009 at 09:54:05
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/john.voltz/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : usb
Using Programmer : avrispmkii
avrdude: usbdev_open(): Found AVRISP mkII, serno: 0000A0011641
avrdude: usbdev_open(): using read endpoint 0x82
AVR Part : ATXMEGA16A4
Chip Erase delay : 0 us
PAGEL : P00
BS2 : P00
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 0
StabDelay : 0
CmdexeDelay : 0
SyncLoops : 0
ByteDelay : 0
PollIndex : 0
PollValue : 0x00
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 0 0 0 0 no 1024 256 0 0 0 0x00 0x00
application 0 0 0 0 no 16384 256 0 0 0 0x00 0x00
apptable 0 0 0 0 no 4096 256 0 0 0 0x00 0x00
boot 0 0 0 0 no 4096 256 0 0 0 0x00 0x00
flash 0 0 0 0 no 20480 256 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 512 256 0 0 0 0x00 0x00
usersig 0 0 0 0 no 512 256 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
fuse0 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse1 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse2 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse4 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse5 0 0 0 0 no 1 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 0 0 0x00 0x00

Programmer Type : STK500V2
Description : Atmel AVR ISP mkII
Programmer Model: AVRISP mkII
Hardware Version: 1
Firmware Version Master : 1.12
Vtarget : 3.2 V
SCK period : 4.00 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATXMEGA16A4 is 1E 94 41
avrdude: reading input file "0xde"
avrdude: writing fuse0 (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of fuse0 written
avrdude: verifying fuse0 memory against 0xde:
avrdude: load data fuse0 data from input file 0xde:
avrdude: input file 0xde contains 1 bytes
avrdude: reading on-chip fuse0 data:

Reading | ################################################## | 100% 0.00s

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

avrdude: safemode: Fuses OK

avrdude done. Thank you.

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I found the answer. AVRDUDE 5.8 is broken. It looks like someone started making some changes to stk500v2.c and never finished. Attached is a patch that fixes it.

Attachment(s): 

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's enough to drive me mad, avrdude still doesn't work right. It will work if I run it in gdb with a breakpoint, but if I turn off the breakpoint, it won't work. WTF?

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
enough to drive me mad
1st sign of madness is when you talk to yourself, the 2nd is when you start answering yourself. If I was a doctor i'd have enough to have you committed. :wink:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a habit of doing that. It actually helps me think, by verbalizing my problem. Then our network crashed, and my train of thought was completely derailed.

I'm not afraid to admit that I'm insane, my wife already knows it. So does my doctor. Bwah ha ha.

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was able to get my AVRISPmkII to program an Xmega via avrdude after swapping someone else's avrdude.conf in for mine. I'm trying find where I found it now.
It's here: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=download&id=16752

-Raliegh

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It will work if I run it in gdb with a breakpoint, but if I turn off the breakpoint, it won't work. WTF?

So it's a timing issue? Try putting in a humungous delay where the breakpoint was positioned. (I know it's a fudge but it often works)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

So it's a timing issue? Try putting in a humungous delay where the breakpoint was positioned. (I know it's a fudge but it often works)

That's the thing, I tried that and it didn't help. It's one of the weirdest things I've seen. I'll definitely post back with the fix, if I figure it out.

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, my for loop delay apparently got optimized out or something. I used usleep(100000); and it works now. I'll send my findings to Jörg, and see what he thinks.

Attachment(s): 

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's an example showing how to program an XMEGA using avrdude, since I noticed that it is documented nowhere.

avrdude  -cavrispmkII -px16a4 -Pusb -e -Ufuse0:w:0xff:m -Ufuse1:w:0x66:m -Ufuse2:w:0x7f:m -Ufuse4:w:0xf0:m -Ufuse5:w:0xea:m -Uflash:w:my_prog.hex:i -Ulock:w:0x00:m

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,
I tried the patch on the stk600, but it still does not work :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obor00 wrote:
Hello,
I tried the patch on the stk600, but it still does not work :(

Try increasing the delay I added in the patch. Also, check the /etc/avrdude.conf and make sure the offsets for the part you are using are right. It works for me now with the AVRISPmkII, in Linux. I used it with the ATxmega16A4. We use Linux for production programming, so I had to fix it for this new design.

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI, I just tested the patch with my STK600 and it worked fine programming the ATxmega16A4.

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hear you have an JTAGICEmkII, but I also see you patching "stk500v2", does this mean that the stk500v2 can use the PDI interface without modification to the firmware?

I have several stk500v2 emulating programmers, and I'd like to program my xplain.... :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rewolff wrote:
I hear you have an JTAGICEmkII, but I also see you patching "stk500v2", does this mean that the stk500v2 can use the PDI interface without modification to the firmware?
No, the STK600 uses a different protocol to the stk500v2. A lot of the difference is actually wrappering existing skt500v2 or JTAG commands. Hence rather than creating a brand new source code called stk600.c or whatever, the authors of AVRDUDE chose to extend an existing file called stk500v2.c

--Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well damn. I just pulled my hair out trying to work out why AVRStudio worked with my PDI programmer, and not avrdude. I looked over the avrdude source, found that issue and patched it myself -- then stumbled across this. Oh well, good work and I hope it makes it into the avrdude trunk soon.

One more thing which needs to be patched is to send the SET PARAM command for the NVM base address *before* the ENTER PROGRAMMING MODE for PDI, as the latter needs the former to work correctly. While the official programmers apparently have the NVM base parameter set to a default value, having this reversed means that the parameter is useless if the base address ever changes, since the programmer won't be able to enter programming mode with the target.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using AVRStudio and the AVR ISP mkII? I would like to program a new XMega raw chip with my mkII, but I have been having difficulty finding a good tutorial on clock settings, fuses, and doing this all in AVRStudio. Any suggestions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Dean

Just to sum up :
Was all you needed a "clean" avrdude 5.8 , and the above patch ?

No "forreign" configfiles or the NVM stuff you talk about ?

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is avrdude 5.8 (Linux binary) w. the above patch applied , and build with the avr-gcc build-script (build on Ubuntu 8.04).

1: rename from avrdude.zip to avrdude.tgz (freaks don't like .tgz attachments).

2: extract & copy to /usr/local/avr/bin
i havent tested it yet , so please backup the old avrdude executable first

Just updated the Debian install package here (use 17-dec)
http://www.wrightflyer.co.uk/avr...

This package (system) has been tested , but you might want to read a bit here.
https://www.avrfreaks.net/index.p...

/Bingo

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry Bingo - something seems to be eating some of my AVRFreaks notifications.

Yes, PDI programming worked once I applied the patch straight to the trunk. However, that doesn't solve all the issues; there are two outstanding:

1) PDI SET PARAM command is being set *after* the ENTER PDI PROGRAMMING command, breaking compatibility with any XMEGA that has the NVM base address different to the default
2) Interactive terminal flash reads seem to be unbearably slow, despite command line -U flash:r:readback.hex commands working fine

I can submit a patch for the former quite easily, but haven't looked into the latter. I'm happy to do so, but I'd like to see the above patch in the trunk first before I potentially waste my efforts.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Dean

Well i did apply it to a "Clean" avrdude-5.8.tar.gz , not the trunk.

The patch went ok , but i wonder if it works ..

I'll have to do an upgrade of the Xplain firmware , and then connect to my Linux

Hmmm....

Well i'll "make the USB firmware" from lufa (a fresh svn co), and upgrade the USB Mega on the xplain , using a dragon & avrdude.

Well i can see ArnoldB is using dfu-programmer , http://dfu-programmer.sourceforg...
https://www.avrfreaks.net/index.p...

I'll give it a try :-)

I just build this one on my ubuntu
http://sourceforge.net/projects/...

Just downloading , extracting , do a "./configure" and a make. (Skip bootstrap)

I'll be BACK :-)

Btw: Should i expect success or failure , now that i don't have the NVM patch ?

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well i skipped the dfu-programmer , it kept saying there was no device connected (even if i shorted pin 1 & 2 on the jtag)
Maybe i needed some kind of "magic" for my ubuntu . to get it get dfu to see it , its seen by linux as

Quote:
Bus 002 Device 004: ID 03eb:210d Atmel Corp.

and like this after fw upgrade

Quote:
Bus 002 Device 007: ID 03eb:2104 Atmel Corp. AVR ISP mkII

I just used a dragon to put the newly compiled firmware in the usb chip , and read signature succesfully with avrdude

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo600 wrote:
Well i skipped the dfu-programmer , it kept saying there was no device connected (even if i shorted pin 1 & 2 on the jtag)
You also need to ground and release the reset pin.

People didn't believe me when I wrote this first, but my xplain needs this.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Arnold

Hmm ... Strange , is that on the USB avr ?
Is it time critical ?

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the USB AVR J200 header. It is not time critical, but the sequence is relevant.

First short pin 1 and 2. Then short reset on J200 to ground, too. Release reset, and the USB AVR starts the DFU bootloader. The USB AVR then comes up on the USB bus with the bootloader.

After that dfu-programmer has no problem to find the AVR. An erase with dfu-programmer before programming is mandatory.

I have two pushbuttons wired up on J200, one for pin 1/2, the other for reset. This is anyhow more convenient than unplugging/replugging the whole xplain from the USB bus.

With the dragon you might have overwritten the bootloader, so the above procedure might not work any more.

Stealing Proteus doesn't make you an engineer.

Last Edited: Thu. Dec 17, 2009 - 06:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanx Arnold :-)

/Bingo