Last Fall [Kevin] wanted to program some newer TPI-only AVRs using an old USBasp he had kicking around his lab. Finding an “odd famine of information” and “forums filled with incorrect information and schematics”, he decided to set the record straight and document things correctly. He sleuthed out the details and succeeded in reprogramming the USBasp, although he did end up buying a second one in the process.
Designers who use AVR microcontrollers have no shortage of programming interfaces — we count at least five different methods: ISP/SPI, JTAG, TPI, PDI, and UPDI. We’re not sure whether this is variety is good or bad, but it is what it is. [Kevin] discovers that for the particular family of Attiny devices he is using, the ATtiny20, TPI is the only option available.
While he normally builds his designs around ARM Cortex-M chips, [Kevin] needed some glue logic and decided to go with an ATtiny20 despite its unique programming requirements. He observes that the price of the ATtiny20, $0.53 last Fall, was cheaper than the equivalent logic gates he needed. This particular chip is also quite small — only 3 mm square (a 20-pin VQFN). We would prefer not to use different MCUs and tool chains on a single board, but sometimes the convenience and economics steer the design in that direction.
If you’re not familiar with the USBasp, our own [Mike Szczys] covered the breaking story over ten years ago. And if you have a lot of free time on your hands, ditch all these nicely packaged solutions and program your chips using an old USB Hub and a 74HCT00 NAND gate as described in this bizarre hack by Teensy developer [Paul Stoffregen].
I solved this problem for the USBTiny and Raspberry Pi SPI programmers.
https://hackaday.io/project/172310-usbtinyisp-to-tpi-adapter
Having all those different interfaces for programming is a bad thing. For me it’s simply part of the reason I do not use a lot of the AVR processors. I started long ago with the 16F84 and a few wires between a breadboard and an LPT to program it, but quickly decided that programming that thing in ASM was too much of a bore. Then came the AT90S2313 and later ATMEGA8 and got myself bootstrapped again with the LPT port to program an AN910 programmer on a serial port. (This was all way before “arduino” existed) ATmega8 and 328 have filled most of my processing needs for uC’s for quite some years.
You’re also forgetting some other programming interfaces:
“High voltage Parallel” is sometimes used as a last resort to recover from faulty fuse settings (and those fuses never should have been there in the first place) And I see some reference of “aWire”. Yeah sure, a new programming interface every 3 years. Just Yuck!
https://en.wikipedia.org/wiki/AVR_microcontrollers#Programming_interfaces
I briefly tried the ATTINY2313, and then quickly discovered that I2C was completely incompatible with the M328 and I had no interest in re-writing my driver again, so I ditched that uC.
I had been tempted to buy the “Dragon” programmer from Atmel at some time. Unfortunately the USD50 thing was so badly designed that lots of them blew themselves up. If there was an undervoltage condition on the USB port, the SMPS kept drawing more current until it self destructed. No thank you, I’m not paying money for that!
Atmel had also not been interested in “Open source” and hobbyists.
Then came the cheap TFT’s from China. The AVR uC’s just don’t cut it to get a decent update rate on those things so I needed something better. I had a look at the Xmega’s, but is was a quite different architecture, so again a learning curve I was not looking forward to. I finally decided to go with STM32. The Blue Pills were real back then and the ST-Link V2 clones were cheap and work. Now the Blue Pills have lost the race to the bottom and I’ve got 20 or so “Black Pills” from WeAct with an STM32F411 on order. A bunch of small orders because I have to stay below EUR22 for each order, but two of the orders have arrived last week. I’m experimenting now with grblHAL on the STM32F411 and it works. If I need real debugging, I may upgrade one of my ST-Link V2-s (or a Blue Pill) to a “Black Magic Probe”.
Some years ago there was a Hackaday article about reverse-engineering one of the many undocumented AVR programming protocols. I think it was “DebugWire” (has that already been mentioned?) I’d say just stuff it. I’d rather use a uC which has a protocol decoder built in with Sigrok.
About USBasp. Still, my hat of for Thomas Fischl & Obdev for the original design of this thing and bit-banging USB with a microcontroller.
https://www.fischl.de/usbasp/
But these days. There are so many uC’s with hardware support for USB that bitbanging USB is mostly a relic of the past…
Except…
Using this can be a great low-cost introduction to learning the itty nitty gritty details of low level USB protocols. It only uses low-speed USB, which is 1.5Mbit/s and this can be caught with a cheap Logic Analyser and Sigrok. Sigrok has decoders for the low level USB stuff and you get a wealth of information this way. From bit stuffing, checksums, initialization and all those other things. You also get to start with a working application (USBasp) and the sourcecode of USBasp is freely available and well written and documented. Reading C code is also easier for me than deciphering datasheets and what registers of some hardware USB peripheral is supposed to do.
Reading datasheet/programming manual is easier for me and according to one vendor should be consider as the primary source of material – even in case their own library have any conflicting info vs the datasheet.
To me, 3rd party info such as social media is pretty much hearsay/Chinese whispers no matter how convient they are.
I have to agree that Atmel has no interest in hobbiests or even smaller customers. Years back, I was involved in a project to make 600 of a device using a 90S2313. I called the local rep to get a sample so I could test out my programming fixture (which ended up having problems we only found in production because of course a chip needs an XTAL to program, not) but they never even returned my call for over 8 weeks. By then, the project was over and everything was shipped. At least Digikey stocked and shipped the chips in a timely fashon.
Decided to refust any project with Atmel chips in it from there on. I avoided the whole Arduino craze because of it.
Having too many programming/debugging protocols is a sign that the design team don’t plan ahead. Worse of all is that the *hardware debugging* (not programming) protocols are not docmented for open source supports.
AVR parts are not performance per price competitive. I have converted over to the $0.20 STM8F003 for 8-bit uP projects. I even branched and ryng to clean up a STM8 VUSB. I would use the STM32 for anything else that needs more performance/memory/peripherals.
I have an STM8 devboard here, if you have any insteresting vusb stm8 firmware I could play with…
We have DirtyJTAG on an stm32, maybe it can be ported to STM8 as well.
There are hardware limitations for USB pins because of the instruction set. BUlk pipes not supported as it is not allowed in USB low speed. i.e.same limitation as AVR VUSB – no mass storage device, no USB serial.
Look under FPGA-Computer on github. Each project is different as they exercise different code paths. I have STM8-LCDUSB (USB with vendor command and trick to use GPIO pin that original author said not possible) and STM8-HID-Multimedia-Dial. I am hoping to port something else but getting parts shipped or finding motivation during COVID is hard.
The USB stack is from github user BBS215 STM8S-VUSB-KEYBOARD project. I have google translated all the comments, replaced the bloated library with bare metal, modify code to add vendor command support etc. The code is still much more complex than what it should be (vs AVR VUSB) and could use some refactoring.
Using an 8-bit micro instead of a logic gate is (un)planned obsolescence, since the flash memory is only guaranteed to retain data for 20 years.
That’s at a constant 85C though. A 1ppm failure rate with 100 years at 25C tells me that flash will probably outlive many caps and other parts. It won’t be the weakest link in “planned obsolescence”.
Aside from that, can you even call a 20 year component failure time planned obsolescence in today’s world when “standards” move far faster than that?
Plus how quaint an AVR will be in 20 years. The kids will probably be playing with “micrcontrollers” with the equivalent to today’s i9 inside something the size of a grain of rice.
I have computer fans that have been spinning for 20 years. No I wouldn’t.
I mean, yes I would call that planned obsolescence. I wouldn’t put a cheap EEPROM of a flash chip in anything that goes inside a wall, in a car, in a home appliance or automation product… etc. device that one might reasonably expect to keep on working, because it means it will be a discontinued part in an obsolete device with no spares available when it does break, so it becomes impossible to repair.
Also, since an MCU is essentially a black box, you can’t tell from the circuit diagram or the wiring what its function is – again, makes it very hard to reverse-engineer and repair.
An AVR Atmega328p has 1 million gates, wtf.
I have 2 Cisco consumer product that suffered FLASH corruptions before their “20 years”. FLASH chip quality might play a part…
[Kevin]’s solution requires TWO USBasp’s, one to program the other with the “new” TPI capable firmware.
Look here:
https://blog.podkalicki.com/how-to-update-avr-usbasp-firmware-to-latest-version/
Look here:
https://www.fischl.de/usbasp/
See this:
usbasp.2011-05-28.tar.gz (519 kB) TPI support, supports programmers with ATMega88 and ATMega8
I looked in the usbasp.2011-05-28 Changelog.txt file and saw this:
usbasp.2011-05-28 (v1.4)
————————
– added TPI support for ATTiny4/5/6/10 (by Slawomir Fraś)
– added support for controllers with flash >128kb (by Slawomir Fraś)
– fixed resync after program enable signal to pulse RST (based on patch by Marco S)
– updated usb driver to V-USB Release 2010-07-15
Yeah the ATtiny20 that [Kevin] is targeting isn’t specifically mentioned in the changelog, but that shouldn’t matter; TPI is just TPI, right?
IMHO I would prefer to see the USBasp programmed by an Arduino so you don’t need to buy a second Chinese USBasp clone with old firmware. But I wasn’t able to find an explanation on how to do exactly that. However there are plenty of explanations on how to clone an AVRISP mkII with an Arduino (one link below is an example), which should get the job done.
But never mind that. There are instructions available on how to program an ATtiny using TPI DIRECTLY from an Arduino! So just chuck that lousy USBasp with the outdated firmware. Here are two examples:
This:
https://hackaday.com/2012/08/23/programming-the-attiny10-with-an-arduino/
Leads to this:
http://junkplusarduino.blogspot.com/p/attiny10-resources.html
And this:
https://hackaday.com/2017/01/06/usb-arduino-into-avr-tpi-programmer/
Leads to this:
https://make.kosakalab.com/make/electronic-work/avrisp-mk2/uno-r3_avrisp-mk2_en/
I recently worked with some ATtiny10 devices.
I tried the arduino tpi stuff. It wasn’t easy to use, and became very tedious.
USBasp with the latest firmware worked great. I don’t think there is anything more needed for the timy20, is there?
Hmmm… So the Devil is in the actual doing (or attempting to do). Good to know.
I have seen some guy transforming this flasher into a JTAG adaptor, but I can’t find the link back…
Ok, so the micro is cheaper than the logic chips, but there’s a production step now of programming and testing the micro. Plus, that programming system must be available for all time going forward.
Yes, I know, it’s swings or roundabouts.
* For appropriate values of “for all time”