pymcuprog repeated read gives different results

[Sojourneer]

I have been getting verify errors on UPDI programming with pymcuprog, regardless of the upload speed I choose. I used the command line reported in Arduino IDE to run prog.py standalone, and eventually found that consecutive repeated reads to the same Tiny824 chip was reading different results (and also different from the .ino.hex). It is usually a 1 or sometimes 2 bit difference, in multiple places.

I'm using a common SerialUSB board with a diode between Tx and Rx as specified in this repository's instructions. It seems unlikely to me that the uploads are as badly corrupted as is being reported by the upload tool's verify phase. I suspect the read for verification is faulty.

[hmeijdam]

What happens if you upload from within the IDE?

[Sojourneer]

What happens if you upload from within the IDE?

Verify errors.

I have since swapped the USBSerial adapter, and the problems have disappeared. It seems it had become erratic. I'll close the issue.

[SpenceKonde]

Yup, this happens often with USB serial adapters converted to this use. there are only a few failure modes, as these devices are really fuckin simple. The only failure specific to the modified serial adapter is that the external component can fall off, or be damaged (this happens quite easily if you stick SOT-23 diodes between the pins of the serial header, which I used to do until I found 2 broken ones within a single day (as in, the component itself was cracked, because it wasn't properly supported and mounted). There is the uncommon failure mode involving an actual failure of the USB serial adapter too, like anything, but this application isn't one that tends to heap abuse on the adapter or anything. That leaves one cause of failure left, and it has caused the vast majority of hardware problems with UPDI. I think what it comes down to is that fake dupont terminals, facing frequent reconnection cycles and pulls on the wires in unusual directions more often than most devices, are just not up for the task. The DuPont connector has a very long heritage - it dates back at least half a century. The housings were much nicer then - all the colors of the rainbow for color coding, and you'd insert the pins with the housing's plastic angled down, then straighten it to lock them in place.

Of course, using real DuPont terminals solves the reliability problems - the cause is Harwin wanting to replicate the small outline of the connector, but avoid the need for a leaf spring of a different metal, greatly complicating manufacture compared to a single piece of stamped brass. Obviously DuPont wasn't so dumb as to not realize that there was a way to do it with stamped brass too, but they produced quality products designed for reliability, had probably tried a non-leaf-sprung version, found it to be wanting, and went for the backup design with a leaf spring, and tested it rigorously. They cost a damned fortune. Currently the terminals cost $0.25 each, instead of $0.025 for the chinese copy of Harwin's crap (note that Harwin's version sucks just as bad as the best of the chinese clones. This connector is actually doing something very unusual. It fits into a 0.1" square, and hence can use housings for single row, or double row and so on but this means there's no second mechanism for retention - all of the force for both the electrical contact and holding the connector onto the pin has to come from the same source. A leaf spring is effective. Stamped brass is not. DuPont's datasheet for gold plated terminals specifies 1000 connection cycles followed by several hours in a moist hydrogen sulfide atmosphere (highly corrosive), after which the contact resistance is supposed to still be below a minimum value. Harwin specified 100 connection and disconnection cycles for the gold-plated M20's. No corrosive atmosphere, and no maximum resistance specified. The specs of the Chinese ones would probably be worse if they bothered to publish them, but Harwin's spec is pretty lousy. And remember that is not considering the damage that would be caused by handling that is not part of a connect or disconnect cycle throughout that many cycles.

I think it's that last part that causes a lot of the problems with programmers, especially for UPDI. It's the cable, held on by only 3 terminals on either end, with the USB serial adapter attached to a cable that wants to go one way, the board wired to something in the other direction, everything exerting strain in various directions on the wires... and all that force has to come from the thing that maintains the electrical connection too. Which is not made from spring steel, or spring-anything, but from simple stamped brass, which is a terrible spring, and deforms rather quickly and stops making a reliable connection. I periodically replace the terminals on my programmers because of this... these mysterious suddenly flakey connectors happen far more often on UPDI than FTDI, because FTDI has 6 pins and a longer aspect ratio that keeps the connector deflection in that direction. At the USB-serial connector end, you will likely have three out of 6 holes on the dupont housing filled. The connectors last longer if you clip off the terminals from otherwise damaged cables and insert them in the unused holes to grab onto the unused pins, helping to hold the connector in place.