ICSP programming of the (tr)uSDX

I noted some online discussions where some people had troubles using an ICSP programmer to program the MCU.

I do not have a (tr)uSDX, but inspection of the schematic does hint what those users are doing wrong.

Loading the SCK, MOSI and MISO lines risks problems with operation of the SPI protocol used, but the effect depends to some extent on the driver, length and type of interconnecting cable etc.

Here are some measurements of a USBasp driving an Arduino board with 5V Atmega328P 16MHz chip using about 200mm of ribbon cable… AND the MOSI line is loaded with a 0.01µF capacitor (as in the (tr)uSDX schematic).

As mentioned, ISCP uses an SPI protocol and the capture above uses yellow for SCK and red for MOSI.

Note that the MOSI rise time is about 1µS, and recall that MOSI is sampled at the rising edge of SCK. The very first rising transition of SCK probably samples MOSI to be logical 1 (since it is more than about 1V)… but in fact it is slowly on its way to logical 0, and has been for 0.5µs. As mentioned, different cable types and lengths, and different programmers are likely to give different results, and some might resolve this bit correctly, others might not.

But that is not what digital systems are about!

Above is the same scenario WITHOUT the 0.1µ capacitor on MOSI. There is no confusion about the value of MOSI around the rising edge of SCK… it works reliably.

The (tr)uSDX shares the MOSI pin with the external PA control jack J9 and filters the line with a 0.1µF capacitor, the work around is to slow the programmer bit rate down so that the slowed MOSI rise and fall do not cause errors, a bit clock rate of 100kHz or less (AVRDUDE -B8 command line option with USBasp) should be reliable… though of course slower to program the chip.

Above is a datastream clocked at 93.75kHz, it can be seen that the rise time is now acceptable for the SCK rate.

The default rate for AVRDUDE and USBasp is 375kHz. It would probably work most of the time in my test setup… but digital systems are about stuff that works ALL the time.

Some software and programmers may not provide a convenient way to slow the clock rate, for example the recommended ArduinoISP may require you adjust source code, the source code default is 167kHz, change to #define SPI_CLOCK (100000). Again, the default probably works MOST of the time, but reducing speed will make it more reliable (given the heavy MOSI filtering discussed above).

My own practice with these type of systems is to use a bat file to invoke AVRDUDE with the correct fuse settings (see WriteOptiBoot.bat), and to erase / unlock / lock the boot region to protect the boot loader from accidental damage. The bat file serves to document to required settings, and reduces the risk of accidental writing of wrong fuse values that is so easy with a GUI such as AVRDUDESS.

Above, the default fuse settings when AVRDUDESS is opened. Hitting the Write button may make changes that are very difficult to recover.

Far and away, the most common cause of unreliability in ICSP is wrong / unreliable connections or unstable / insufficient power. Don’t power the target from the programmer unless you are sure there is sufficient capacity.

Learn to read and properly interpret the AVRDUDE log, checking carefully the verify steps for sizes.

The ‘fix’ proposed by some to remove the 0.1µF capacitor might solve the ICSP issue, but create other problems, particularly if J9 is used for an external connection.

At the end of the day, this is a user problem, perhaps fueled by a lack of documentation of reliable programming speeds.