Turning A Microchip MPLAB Snap Into A UDPI AVR Programmer

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)

20 thoughts on “Turning A Microchip MPLAB Snap Into A UDPI AVR Programmer

  1. Who would even use Microchip these days when they are out of stock of nearly everything. A total failure on MC part to have no other resources to make silicon. Where others were able to.

    1. I thought the reasons to avoid Microchip had more to do with the godawful trainwreck they’ve made of their documentation (“Oh, you wanted a reference manual? Have a usually-broken website with 47 separate PDFs for various peripherals and aspects of the CPU instead, and some of the peripherals in your chip just won’t be covered”), the driver library code that’s riddled with “My Fir5t ardUinO SkEtch” level bugs, and support that ghosts you for a month or two at a time.

    2. Agree to Disagree, Mike
      On balance all vendors/manufacturers had serious stock problems. All of them, no exceptions.
      But recently you can see gradual improvement in this situation.
      My occupation is 95% Supply Chain Management.

    3. Microchip isn’t out of stock, and neither are most other manufacturers. You’re just not a big enough client to afford a supply contract, and there’s no reason for a manufacturer to cater to you, specifically, instead of customers who buy millions of units at a time.

  2. I feel like Microchip is bitter no one wanted to use PICs with proprietary compilers and stupid expensive/complicated programmers. Now they bought Atmel and are trying to get people used to more crappy support for stuff.

  3. Yes, developing DIY/modded programmers for proprietary chips is doable. Heck we’ve done it myself. But there is the risk (as you’ve noted) of ending up kinda stuck when the manufacturer introduces new chips, unless you devote effort to keeping up with their product introductions. And then there is the issue of verifying that the DIY programmer works with each new chip. This can be tricky. Microchip has a whole staff devoted to adding support for new products to their “ICE” debugger/programmers and making sure they keep working. If you can build cheaper programmer hardware for their chips, so can Microchip. Believe me, they have zero incentive to creating a barrier-to-entry by overcharging for their programmers. My recommendation: Work with them. Start by contacting your local rep.

  4. > an afterthought for Microchip.

    Well, yeah. I can see it now. “With the external programming pins connected to general purpose IO pins of the powerful SAMxxx, we’ll be able to support ANY protocol!” “You did WHAT???!”

  5. I am using Snap for almost 2 years for programming ATtiny202 without any problems. Of course I had to modify the Snap according to ETN #36 MPLAB® SNAP AVR UPDI/PDI/TPI Interface Modification as mentioned in the artcile here. Snap is also great for debuging.

    Yesterday I finished the Laser Cat Toy with ATtiny202 using random number generator, 2 PWM for servo control a custom delay function to fit program into 2 kB of ATtiny Flash.

    https://www.youtube.com/watch?v=6FISEYpp3zI
    https://www.youtube.com/watch?v=PSJurUUFpoA

    1. that is a good summary, i am using the cheap ATTiny416-Xplained-Nano – there are three zero ohm links to remove and then the updi pin is free to program other attinys – in the ide you need to change a setting to allow the programmer to talk to chips other than attiny416 – i have only tried it with other attiny x1x chips and it works well, not sure about megas, etc

Leave a Reply to WestfWCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.