Increase XMEGA/PDI programming speed

[Tropaion]

Hello,
I'm programming a software for serial production which programs an XMEGA/PDI and checks some things.
This is my programming command:
avrdude.exe -c atmelice_pdi -P usb:J41800038194 -B ?? -p x384c3 -e -l out.txt -U flash:w:bootloader.hex -U flash:w:firmware.hex -U eeprom:w:eeprom.hex -U fuse1:w:0xFF:m -U fuse2:w:0xBF:m -U fuse4:w:0xFE:m -U fuse5:w:0xEb:m -U lock:w:0xfc:m
It works, but the problem is, it takes very long.
At first I used the mk2 which took about 30s to program but was very unstable (I often got some errors).
Now I switched to the atmel ice, which works really stable but is much slower.
So I tried to tweak with the -B parameter, but barely got any satisfactory results:

-B 0.5 = 44.94450283050537s
-B 0.3 = 44.12700653076172s
-B 1 = 51.25245475769043s
-B 2 = 60.83038020133972s

With 0.5 its ~15s slower than mk2. And whats confusing me, since this is the bit clock period, shouldn't the speed increase be linear? Did I set some parameter wrong?
Is there maybe an even better PDI programmer for fast programming in production use? Haven't really found anything.

I hope someone can help me,
Tropaion

[stefanrueger]

shouldn't the speed increase be linear?

Reading without overhead perhaps, writing needs to program flash in addition to comms. And there is always protocol overhead, so no. Here an estimate on the back of a schematics drawing: Erasing and writing a page will be some 10 ms, probably a bit less. At 512 byte in a page there are 768 pages, so we have 6-8 s programming time for writing all of flash once. Flash has around 3m bits, so with a bitclock of 1 MHz we have min 3 s for pushing flash from the programmer to the target and another 3 s for reading it to verify (realistically more like 5 s each). The programmer also needs to maintain a comms link to the host, where the data ultimately come from and return to. That comms stream could conceivably run concurrently and be faster, so no time burden. We don't know how big your two files are and how efficient the two .hex files encode the applications (if the .hex files use holes programming is a lot faster and worst case the two uploads write most of flash twice). So, in absence of any more info, 30 s is cool. Not sure one can expect much better.

Ultimately it comes down to the programmer HW, how well its firmware is written and protocol overhead.

[stefanrueger]

often really unstable and unreliable, not suitable for production

Many tries with the same programmer instance or many different AVRISP MkII programmers that gave you that experience? We don't hear much about stability problems for the mkII, but there is sometimes trouble with contacts and cables with all sorts of programmers.

[MCUdude]

I've never had any issues with the AVRISPmkII in PDI mode. It's fast and very reliable. The AVR Dragon however (similar to the JTAGmkII), is another story. Mine is very unreliable and just stops working from time to time.

[stefanrueger]

I have recently bought a cheapo AVRISPmkII from Aliexpress and it works well, at least in the few tests for PRs, eg, this one

[mcuee]

I have quite a few AVRISP mkII clones from Taobao/Tmall and they are all working fine. It is one of the recommended programmer in the below avrdude FAQ.
https://github.com/avrdudes/avrdude/wiki/FAQ#i-am-new-to-avrdude-and-i-do-not-have-a-programmer-what-are-the-recommended-programmers-to-be-used-with-avrdude

[mcuee]

If we look at Microchip/Atmel's AN2468, then it is true that Atmel ICE and AVRISP mkII are not considered as producton grade programmers, but only for development.
https://ww1.microchip.com/downloads/en/AppNotes/00002468A.pdf

[stefanrueger]

how to recognize if it has holes

Use -c dryrun instead your actual programmer and look at the commentary. For example

$ avrdude -c dryrun -p m1284 -U atmega1284_16mhz_wevaf10_ledPD0_wdto1s.hex

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9706 (probably m1284)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip

avrdude: processing -U flash:w:atmega1284_16mhz_wevaf10_ledPD0_wdto1s.hex:i
avrdude: reading 438 bytes for flash from input file atmega1284_16mhz_wevaf10_ledPD0_wdto1s.hex
         in 2 sections of [0x1fe00, 0x1ffff]: 2 pages and 74 pad bytes
         writing 438 bytes to flash ...
         writing | ################################################## | 100% 0.00 s 
         reading | ################################################## | 100% 0.00 s 
         438 bytes of flash verified

avrdude done.  Thank you.

This tells us that the bootloader is in 2 sections of 2 pages occupying 438 bytes. Very reasonable. If flash of the such prepared part were written to a backup file and that uploaded, this would be much less efficient:

$ avrdude -qq -c dryrun -p m1284 -U atmega1284_16mhz_wevaf10_ledPD0_wdto1s.hex -U flash:r:backup.hex:I

$ avrdude -c dryrun -p m1284 -U flash:w:backup.hex:I

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9706 (probably m1284)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip

avrdude: processing -U flash:w:backup.hex:I
avrdude: reading 131072 bytes for flash from input file backup.hex
         in 1 section [0, 0x1ffff]: 512 pages and 0 pad bytes
         writing 131072 bytes to flash ...
         writing | ################################################## | 100% 0.00 s 
         reading | ################################################## | 100% 0.00 s 
         131072 bytes of flash verified

avrdude done.  Thank you.

should be able to safely program up to 26 MHz

... assuming ideal conditions otherwise? short good-quality cables, twisted pair drivers, digital isolators, high-quality programmer HW using an MCU that can actually generate 26 MHz and handle comms at that speed, a fine-tuned programmer firmware that focuses on speed etc

I am not surprised the standard setup tops out at 7-8 MHz.

What's the use case? Programming small batches of 3600 production runs every month, where shaving 1 s off the programming time translates to saving 1 hour for you?

[MCUdude]

I haven't not been able to get more than 7-8 MHz out of my Power Debugger, which is essentially an Atmel ICE with more memory for debugging. The SNAP/Pickit4 is much, much slower.