The Unified Program and Debug Interface (UPDI) is Microchip’s proprietary interface for programming and on-chip debugging, and has become the standard on AVR MCUs after Microchip’s purchase of Atmel. Being a proprietary interface means that even entry-level programmers like the Atmel-ICE are rather expensive at over $100. That’s when for [Scott W Harden] the question arose of whether the much cheaper MPLAB Snap board (~$34) could be used as well for AVR UDPI purposes.
The stages of grief that [Scott] went through before he had it working involved among others the updating of the MPLAB Snap board firmware, getting yelled at by the Microchip Studio IDE when attempting to use the Snap for AVR MCU programming, and ultimately fixing the board following the relevant Microchip Engineering Technical Note (ETN #36) that specifies the removal of a 4.7 kΩ pull-down resistor (R48) on the Snap board. This allows the UDPI line to be pulled high by the MCU.
As the ETN notes, an external pull-up may also be used to override the pull-down, which would leave the ICSP functionality of of the Snap intact. As [Scott] mentions in his conclusion, it feels as if UDPI AVR support with the Snap is really an afterthought for Microchip. Meanwhile there are also more DIY solutions as [Scott] adds, which are useful for just flashing the MCU. An example is with a USB-TTL serial adapter and pymcuprog.
The problem with DIY solutions like jtag2updi, ftdi2updi, and their kin is the effort required to assemble them, and the uncertainty of long-term support as the UPDI ecosystem keeps evolving with new devices and new features. The MPLAB Snap with resistor mod may be just that middle ground between an Atmel-ICE and reverse-engineered OSS projects.
(Featured image: MPLAB Snap resistor mod illustrated, from Microchip ETN #36)
If there’s one thing we’ve learned over the years, it’s that if it’s got a silicon chip inside, it could be carrying a virus. Research by one group focused on hiding a trojan inside an AVR Arduino bootloader, proving even our little hobbyist microcontrollers aren’t safe.
The specific aim of the research was to hide a trojan inside the bootloader of an AVR chip itself. This would allow the trojan to remain present on something like a 3D printer even if the main firmware itself was reinstalled. The trojan would still be able to have an effect on the printer’s performance from its dastardly hiding place, but would be more difficult to notice and remove.
The target of the work was the ATmega328P, commonly used in 3D printers, in particular those using the Marlin firmware. For the full technical details, you can dive in and read the research paper for yourself. In basic terms, though, the modified bootloader was able to use the chip’s IVSEL register to allow bootloader execution after boot via interrupt. When an interrupt is called, execution passes to the trojan-infected bootloader’s special code, before then returning to the program’s own interrupt to avoid raising suspicion. The trojan can also execute after the program’s interrupt code too, increasing the flexibility of the attack. Continue reading “Trojans Can Lurk Inside AVR Bootloaders”
Making a small number of things with an embedded application is pretty straightforward, you usually simply plug in a programmer or debugger dongle (such as an AVRISP2) into your board with an appropriate adaptor cable, load your code into whatever IDE tool is appropriate for the device and hit the program button. But when you scale up a bit to hundreds or thousands of units, this way of working just won’t cut it. Add in any functional or defect-oriented testing you need, and you’re going to need a custom programming rig.
Adafruit have a fair bit of experience with building embedded boards and dealing with the appropriate testing and programming, and now they’ve updated their AVR Programming library to support the latest devices which have moved to the UPDI (Unified Programming and Debug Interface) programming interface. UPDI is a single-wire bidirectional asynchronous serial interface which enables programming and debugging of embedded applications on slew of the new AVR branded devices from Microchip. An example would be the AVR128DAxx which this scribe has been tinkering with lately because it is cheap, has excellent capacitive touch support, and is available in a prototype-friendly 28-pin SOIC package, making it easy peasy to solder.
The library is intended for use with the Arduino platform, so it should run on a vast array of hardware, without any special requirements, so making a custom programming jig out of hardware lots of us have lying around is not a huge hassle.
Adafruit provide a few application examples in the project GitHub to get you going, such as this ATTiny817 example that wipes the flash memory, sets appropriate fuses and drops in a bootloader.
The UPDI code was taken from the [brandanlane’s] portaprog which is hosted on the TTGO T-Display ESP32 board from Chinese outfit LilyGo, which is also worth checking out.
A little while ago we saw how the AVR Multitool, the AVRGPP learned to speak UPDI, and since we’re on programming interfaces, its possible to get the cheap-as-chips USBasp to speak TPI as well.
Continue reading “Adafruit AVRProg Grows UPDI Interface Support”
As amazing as CircuitPython is, it hasn’t yet been ported to any 8-bit microcontrollers. [Chris Heo] was unsatisfied with his inability to use Python on his 8-bit ATmega4808 AVR, so he worked out a way to zombify it and bend it to his will using Python on his PC.
The trick to making this all work is the UPDI interface: a single-wire UART interface for programming and debugging Microchip’s newer 8-bit AVR microcontrollers. UPDI reaches deep into the microcontroller’s core, allowing you to stop and start execution of microcontroller code and access all of the onboard data and I/O. [Chris] realized this could be used to stop execution of any code running on the AVR and directly control the output pins using the pyupdi library. Since UPDI lets him modify the AVR’s I/O registers, he was also able to blink an LED and use the microcontrollers UART to send a message back to his PC without compiling a single line of code.
This may seem like an entirely unnecessary hack, but for devices too small or basic to have a JTAG interface for debugging this could be the best way to test and debug peripherals in an assembled circuit. We hope this catches on and would love to see how much of the chip can be controlled in this way. Maybe this will make it easy to experiment with the programmable logic that’s on some of the newer AVRs.
There are two kinds of programmers: those who don’t use Lisp, and those who need new parenthesis keycaps every six months. Lisp is one of those languages you either really love or really hate. If you love it, you may have checked out ulisp, which runs on Arduino boards of the AVR and ARM variety, as well as ESP chips, RISC-V, and others. A recent update allows the language to insert assembler into AVR programs.
We probably don’t need to convince anyone reading Hackaday why adding assembler is a good thing. It seems to integrate well with the environment, too, so you can write assembler macros in Lisp, which opens up many possibilities.
Continue reading “AVR Bare Metal With Lisp”
Join us on Wednesday, April 21 at noon Pacific for the AVR Reverse Engineering Hack Chat with Uri Shaked!
We’ve all become familiar with the Arduino ecosystem by now, to the point where it’s almost trivially easy to whip up a quick project that implements almost every aspect of its functionality strictly in code. It’s incredibly useful, but we tend to lose sight of the fact that our Arduino sketches represent a virtual world where the IDE and a vast selection of libraries abstract away a lot of the complexity of what’s going on inside the AVR microcontroller.
While it’s certainly handy to have an environment that lets you stand up a system in a matter of minutes, it’s hardly the end of the story. There’s a lot to be gained by tapping into the power of assembly programming on the AVR, and learning how to read the datasheet and really run the thing. That was the focus of Uri Shaked’s recent well-received HackadayU course on AVR internals, and it’ll form the basis of this Hack Chat. Then again, since Uri is also leading a Raspberry Pi Pico and RP2040 course on HackadayU in a couple of weeks, we may end up talking about that too. Or we may end up chatting about something else entirely! It’s really hard to where this Hack Chat will go, given Uri’s breadth of interests and expertise, but we’re pretty sure of one thing: it won’t be boring. Make sure you log in and join the chat — where it goes is largely up to you.
Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, April 21 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
Continue reading “AVR Reverse Engineering Hack Chat”
We’ve all got projects kicking around that we haven’t had time to document for our own purposes, let alone expose to the blinding light of the Internet. There are only so many hours in a day, and let’s face it, building the thing is a lot more fun than taking pictures of it. It took [Matthew Millman] the better part of a decade to combine everything he’s learned over the years to finally document the definitive version of his open source intelligent fan controller, but looking at the final result, we’re glad he did.
At the heart of this board is an ATmega328P, but don’t call it an Arduino. [Matthew] makes it very clear that if you want to hack around with the code for this project, you’re going to need to not only have a programmer for said chip, but know your way around AVR-GCC. He’s provided pre-built binaries for those content to run with the default settings, but you’ve still got to get it flashed onto the chip yourself. The project is designed to use the common DS18B20 temperature sensor, and as an added bonus, the firmware can even check if yours is a bootleg (spoilers: there’s an excellent chance it is).
Arguably the most interesting feature of this fan controller is its command line interface. Just plug into the serial port on the board, open your terminal emulator, and you’ll have access to a concise set of functions for querying the sensors as well as setting temperature thresholds and RPM ranges for the fans. There’s even a built-in “help” function should you forget a command or the appropriate syntax.
Originally [Matthew] developed this project as a way to control multiple fans inside of a PC case, but naturally, things have changed quite a bit since those early days. While today there’s no shortage of fancy controllers that can handle throttling an array of fans based on the internal temperature of your rig, there’s still something to be said for rolling your own solution. More importantly, there’s certainly other potential uses for a fully open source programmable fan controller.