Can Arduino UNO with jatag2updi work with MPLAB X?

[DuinoSoar]

(I have seen other HW programmer-related questions here, so I hope this is the right forum category.)

I think this question is more for @DrAzzy (who maintains jtag2updi on github) but, of course, if anyone has an answer, please help to educate me!

I am interested in trying out on-chip debugging (OCD) using UPDI protocol, for the newer UPDI-capable parts (like ATtiny412). But, AFAIK, the Arduino IDE with, any of the available programming tools, is not capable of utilising the on-chip debugging (OCD) features (which some AVR micros have), for source code debugging (setting breakpoints, examining registers, etc.).

So, I am wondering about using MPLAB X (for OCD), and if I really need to invest in a MPLAB Snap or PICKit 4 for debugging, or is there any easy DIY solution for building a UPDI interface to work between MPLAB X and UPDI-capable micros.

So, can an Arduino board (such as UNO), running jtag2updi, be used with MPLAB X? If so, can it be used (with MPLAB X) for both programming AND on-chip debugging of the newer ATtiny UPDI micros?

If not, I think I saw somewhere that there is a way to use a USB-to-serial converter board (such as one based on an FTDI-chip) to communicate with UPDI-capable AVR devices. Could something like that be used with MPLAB X for both programming and OCD?

I guess what I am really looking for is an Arduino sketch that will turn an Arduino UNO into a simplified MPLAB Snap (or some other UPDI interface), and allow the capability of both programming and source code debugging of the newer ATtiny devices.

If not, then I guess I’ll have to buy a Snap or PICKit 4.

Thanks and best regards,
DuinoSoar

[DrAzzy]

For MPLAB, as far as I know you need a proper microchip debugger, it doesn’t support jtag2updi or the pyupdi serial adapter method (even though pyupdi was written by one of their employees and is a feature of pymcuprog which my cores use and which was recently open souced by microchip.

I am planning to discontinue maintenance of the jtag2updi repo. Actually, effectively I already have, but will make it official once we get the serial adapter programming changes implemented properly (rather than hacked on as tests by someone (me) who doesn’t really know python).

Replacing the 4.7k resistor with a schottky diode vastly improved the range of hardware configurations that worked and eliminated the fiddliness that I’d previously experienced.

Previously performance had been slow - 600-1050 bytes/second written. 125 with FT232, a driver configuration option boosts that to the low 900’s. A round of software improvements this week demonstrated improvements by at least a factor of 5 over those numbers while still at 115200 baud, about matching jtag2updi… with the option to go to 230400, and even 460800 baud! I recorded 18kb/sec write and 26kb/sec reads. (jtag2updi is like 5 and 6 respectively)

So now, jtag2updi becomes much less interesting. That, and the code is a totally unmaintainable wad of extremely C+±ey C++ . It is obviously buggy and malfunctions for me routinely, but I am never going back into that code. Updating that for AVR Dx was the least enjoyable bit of embedded programming I have done. I hate everything about jtag2updi, from the extent of the compromises it made for compatibility with the unmaintained avrdude, and to the coding style, to almost every design decision made by the original author, and the programmer whose interface it emulates.

Anyway, you can’t convert an Uno to make an MPLAB compatible programer, but you can with a micro or pro micro, as the hex file for mEDBG is known and has even been tweaked to make it easier to use with the (pro) micro. GitHub - MCUdude/microUPDI: DIY UPDI programmer with open source hardware!
He suggests some really excessive hardware (which is all very lovely)- but the only thing that matters is a 330 ohm resistor between arduino pin 7, and the target device’s UPDI pin (plus power and ground, of course. And I guess the indicator LEDs if you want those

[chrisknightley]

@DrAzzy

GitHub - MCUdude/microUPDI: DIY UPDI programmer with open source hardware!

microUPDI uses mEDBG firmware.
Use from IDE is limited to one AVR chips.

I’m posting a hack that change EEPROM to make it compatible with other AVRs.
See this issues by microUPDIcore repository.

[DrAzzy]

As I read the first thread you linked, there’s an option to ucherck in the official tools that would make it work?

[dlloyd]

@DuinoSoar

If not, then I guess I’ll have to buy a Snap or PICKit 4.

I think the Snap is a great choice! Had some issues getting it setup and working with 8-bit MCUs (needed to select a 32-bit MCU so all appropriate drivers get installed), but once its up and running, well, its a Snap!

Note that if using the Snap debugger for UPDI programming, there is a 4.7K pulldown resistor (R48) that needs to be removed from the UPDI signal.

I’ve also added an adapter (currently on breadboard) that converts the Snap (or any UPDI programmer) into a HV programmer! Luckily, the MPLAB X IPE doesn’t hide any of the HV programmer properties so it works well. I would’ve assembled some Updi-Key boards but after loosing an expensive re-flow oven (due to the pandemic was the excuse), I haven’t pushed further with it.

I haven’t looked into using the SNAP with the Arduino IDE for UPDI programming as I haven’t had any issues using jtag2updi an Arduino Nano programmer … perhaps I’m missing out on something?

[chrisknightley]

@DrAzzy

As I read the first thread you linked, there’s an option to ucherck in the official tools that would make it work?

In the standard state, only one specified AVR chip works.
You can optionally uncheck to “hide unsupported devices” from IDE option.
But set this option unchecked only allows signature reading and not entering program mode.
This was shown in the first linked thread.
Added: Please read bottom of this post.

Applying the hack I posted will added support all devices.
All devices will be displayed even if you don’t uncheck “hide unsupported devices” option.
But it is a hack, all devices that don’t support UPDI will also be fully displayed…
You have to choose the correctly device in yourself, but you can do the programming.

In the attached image you can see the ATtiny1614 programmed using microUPDI on Microchip Studio.
All devices are listed in the dropdown list on the image.

[DuinoSoar]

Thanks for your replies, folks.

@dlloyd

I think the Snap is a great choice!

I think that’s the way I will go. They are about CDN$35.00 from Mouser.ca. (Not sure if there is a lower-cost Canadian vendor. Amazon.ca has a listing for something like $66.00!)

Why does the 4.7 K resistor need to be removed from the Snap board? (I presume you mean “R48” on the board, which is shown unpopulated in your picture.)

Spence, you wrote:

@DrAzzy

[pyupdi] is a feature of pymcuprog which my cores use

I just tried downloading the megaTiny core by adding to the Arduino preferences dialogue:
http://drazzy.com/package_drazzy.com_index.json
(Dang! How does one quote a .json URI without having the forum software trying to turn it into a link? )

But when I tried to install it from the board manager dialogue, I got the following error:

Is there a more up-to-date board definition?

Concerning pyupdi, Spence, you mentioned about using a Schottky diode instead of a 4.7 K resistor. Not sure how that goes. Is it with cathode to Tx and anode to Rx? Will that work with the current programmer sofware from the megaTiny core?

BTW, one does not even need to purchase a dedicated USB-to-Serial interface board, if an Arduino UNO or Nano is at hand (or any Arduino that has a USB interface separate from - i.e. not integrated in - the main Arduino processor chip). Just load an empty sketch into the Arduino (so the 'mega328P keeps all I/O pins high-impedance), and swap the Tx and Rx designations on board pins. (I.e. use the board’s Tx pin as Rx and the boards Rx pin as Tx - because you REALLY want to connect to the REAL Tx and Rx pins for the on-board USB interface.) I suppose the cap between reset and ground would be needed to prevent the programming software from resetting the 'mega328P. (Not sure if the py programming software does that, like the Arduino-as-ISP does.)

[dlloyd]

@DuinoSoar

Why does the 4.7 K resistor need to be removed from the Snap board? (I presume you mean “R48” on the board, which is shown unpopulated in your picture.)

Yep, I “unpopulated” it. The UPDI signal for programming is I/O and has its own internal pullup to VCC. However, the Snap’s R48 is a stronger 4.7K pulldown resistor which definitely prevents any UPDI communication. I guess you could modify the revision to use a jumper to reconnect R48 for non UPDI programming.

[DuinoSoar]

Okay, thanks.

So I am guessing that, in debugging mode, the Snap processor is using internal pullups which have much higher resistance than the 4.7K pull-down, keeping the UPDI output low.

Just wondering: is this (and perhaps other “caveats”) documented in the Microchip documentation for Snap or MPLAB x? (Or anywhere else, for that matter?)

Thanks.

[DrAzzy]

That’s the right version. your problem downloading it is a network problem on your system or a transient connectivity problem. I am able to download that without issue. (silly thing to check - you’re not out of harddrive space are you?) It looks like, decompressed, the toolchain weighs in at 250mb, probably needs that much again as scratch space during installation.

[dlloyd]

@DuinoSoar

Snap processor is using internal pullups which have much higher resistance than the 4.7K pull-down, keeping the UPDI output low.

Its the target processor (ATtiny) with the higher pullup resistance. For more details, check the link in reply#5 (its from Mocrochip).

[westfw]

@DuinoSoar

Just wondering: is this (and perhaps other “caveats”) documented in the Microchip documentation for Snap or MPLAB x? (Or anywhere else, for that matter?)

Yep. https://ww1.microchip.com/downloads/en/DeviceDoc/ETN36_MPLAB%20Snap%20AVR%20Interface%20Modification.pdf

The SNAP->UPDI adapters I made just add a 1k pullup resistor, which also works (over-powers the 4.7k pulldown…)

[DuinoSoar]

Well, now I have to admit to something, Spence. When I was trying to install megaTIny core earlier today, I was at work. (I was taking a break and wanted to explore the new “board” and “programmer” options in the Arduino IDE.)

Anyway, it was probably due to the firewalls or MS group restrictions (which MS whimsically call “group policies”) at work. Our IT security folks tend to get a bit too heavy-handed. I should have realised that was probably the cause of my installation problem.

Anyway, I am now at home and just tried it again, and it installed without problem. Sorry to have troubled you over something that was a problem on my end.