UPDI programmer software for Arduino - compatible with avrdude

Go To Last Post
181 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I've updated jtag2updi so that it can run on tinyAVR-0/1 and megaAVR-0 MCUs with at least 512 bytes of SRAM.

The documentation is not updated yet, I'm doing a long revision and it will take some time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

even not having too much time right now (back working..) I took a look at the UPDI documentation from AVR: As it's 'just' an UART with 8E2 and about 115200-230400 baud, I thought: why not use the 'hardware' UART in the 32U4 for that? That would make it much easier to adopt. So now knowing what to look for I took a second look at the megaavr-core: Yep, they seems do to exactly that.

So I hope that it's easy to fix now after having read a bit of documentation. Maybe I should have done that right from the start ;-)

 

Now my question: Currently it's UPDI_IO_TYPE 1 (software UART) and TYPE 2 (bitbang) in the code. As I don't want to create 'bare metal code' as westw mentioned: Would it a good idea to have UPDI_IO_TYPE 3 for hardware UART, maybe?

 

Or use Serial1 for UDPI automatically if defined? Using '#ifdef HAVE_HWSERIAL1 ... #endif'

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

linuxisgood wrote:
Would it a good idea to have UPDI_IO_TYPE 3 for hardware UART, maybe?

 

Sure, if you can make it work, which won't be easy. Actually type 2 was not written by me, it was contributed by https://github.com/cbalint13 I just made some improvements over time. It's the default now, because it's stable and works with all currently supported chips (i.e. mega328p and similar, mega32, LGT clones and AVR-0/1).

 

The reason it won't be easy, is because you have to tie Tx and Rx together to a single line, so when you send data to Tx it will be looped back to Rx unless you disable it. All this adds complexity and jtag2updi uses pretty tight UPDI timings, unlike pyupdi and MuxTO.

 

Chek out the different configurations (see UPDI datasheet for their meaning):

jtag2updi:

UPDI::stcs(UPDI::reg::Control_A, 6);

UPDI register CTRLB is left in default configuration.
 

 

MuxTO:

  UPDI::stcs(UPDI::reg::Control_B, 8);
  UPDI::stcs(UPDI::reg::Control_A, 0x80);

pyupdi:

Same settings as MuxTO

UPDI_CTRLA_IBDLY_BIT = 7
UPDI_CTRLA_RSD_BIT = 3
UPDI_CTRLB_CCDETDIS_BIT = 3
UPDI_CTRLB_UPDIDIS_BIT = 2

...

    """
       Set the inter-byte delay bit and disable collision detection
    """
    self.stcs(constants.UPDI_CS_CTRLB, 1 << constants.UPDI_CTRLB_CCDETDIS_BIT)
    self.stcs(constants.UPDI_CS_CTRLA, 1 << constants.UPDI_CTRLA_IBDLY_BIT)

 

They had to relax the timings most likely because of the UPDI USART turnaround between Tx and Rx which is very critical, and very well optimized in jtag2updi, thanks to bit banging that provides absolute timing control (as only asm can...). You have to do a deep dive into the code to appreciate such detailssmiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll give it a try. I got an Arduino UNO for playing around with the Attiny from a friend (works fine), so I'm not in a hurry with the 32U4 port. But I'm curious, and optimistic. That usually turns out in task taking longer than expected (sometimes much longer).

I'll implement it in a way that the serial1 (or serial2) has just to be choosen in one place (or will be choosen automatically). Keep you fingers crossed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I added the changes needed for supporting 32U4 now. The SAMD11 MuxTO implements UPDI using hardware-UART, so much of that code could be used. I put the changes into a new fork '32U4_support'.

The UPDI has to be connected as in https://github.com/mraardvark/py....

No switch is done between RX/TX. So no timing issues. After sending a byte that ends up in RX as 'echo'. Compare and delete it and that's it.

 

Trying to program still doesn't work, though. Took me quite some time to figure out why (and I don't know how to fix that):

The Arduino-IDE initializes the COM-port used using handshake RTS/CTS or DTR/DSR (or both). It seems that's ignored by the 328P devices, but the 32U4 seem to use it. And I don't know how to disable that. So I end up in a situation where the 32U4 sends 'SIGN_ON' to UPDI (double_break, STCS+CTRL-A+'6') but fails when trying to send the answer to Arduino-IDE (borrowed a digital scope for that). So it loops sending SIGN_ON for quite some time every 10 sec until failing.

 

So I put a line in JICE_io::put() now, blinking an LED while waiting for the Serial. And it blinks, and blinks, and blinks.

When programming failed and I activate a port in Realterm the answer (from buffer) is sent.

 

Another thing I discovered: Sending the 'sign_on' message two times to 328P (without pause in between) results in only ONE answer, the second request is ignored. When using the 32U4 you get two answers, as USB uses a buffer. Doesn't seem to matter when programming, so I don't know if it's intended or not (or an issue).

 

Last Edited: Sun. Feb 2, 2020 - 11:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice to see that you are making some progress. Just a few guidelines in case you want your code to be included in jtag2updi when it's working:

  • It must have the option to compile in systems without Arduino libraries. So no unconditional "#include <arduino.h>" or similar are allowed, like you have in "sys.h".
  • You can't add hardware dependency to files that don't have it, like "jtag2updi.cpp". If you need to call Arduino initialization functions, do it from "sys.cpp", for example.
  • I would prefer that UART type 3 be in a new separate file, like types 1 and 2.

 

Other than that, thanks for your interest in my program and your effortyes

 

Regarding your problems I have these suggestions:

  • Try to use avrdude directly instead of via the Arduino IDE to see what happens, because the handshake will not be executed (I think it's done by the IDE, not by avrdude. The programmer type used by jtag2updi doesn't include the handshake. Previously I thought it did, that's why I recommended the capacitor to disable the DTR pulse.)
  • Go to the " JTAG2::sign_on()" function in the "JTAG2.cpp" file and change the CTRLA and CTRLB settings to be the same as MuxTO, see post .

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

linuxisgood wrote:
The UPDI has to be connected as in https://github.com/mraardvark/py....
The resistor's value can be an order of magnitude less.

The USB-facing AVR and UPDI AVR should be at the same VCC else a subtle defect can occur (corrected by level shifting, a fast-mode I2C level shift is a speed match to UPDI)

https://www.avrfreaks.net/forum/megaavr-0-series?page=5#comment-2835416

Planet Analog - SIGNAL CHAIN BASICS #66: How to interface a 5V transceiver to a 3V controller - (3/4 page, Figure 5)

Fast Mode - I2C Bus

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW, that kind of connection will loopback everything you send to Tx back to Rx, won't it?

Last Edited: Sun. Feb 2, 2020 - 06:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UART yes, one-wire UART no?, mEDBG no

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it does. The MuxTO solved this by reading Rx after writing, then comparing if Rx==Tx even.

I adopted the Control_A, Control_B in the code to the values as used by MuxTO. Can't tell if those changes in guard-time, delay and collision detection are needed.

Will put it into GIT later.

 

Would it be a good idea to raise an issue about the handling of COM-port? I didn't find where that handshaking could be changed.

For testing UPDI with Avrdude directly I'll have to add the IDs for Tiny202,212,402,412 to the CONF-file, or?

Well, just saw that ElTangas did that already in the CONF included in the github. Didn't try that, yet.

But using IDE would be more comfortable, I think. I raised an issue there: https://github.com/arduino/Ardui...

 

Last Edited: Tue. Feb 4, 2020 - 12:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've tried to use avrdude now, but with the same result:

C:\Program Files (x86)\Arduino\hardware\tools\avr\etc>..\bin\avrdude -c jtag2updi -P COM3 -p t202
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: jtagmkII_getsync(): sign-on command: status -1

 

Pressing CTRL-C, then activating port COM3 in Realterm gives you 'sgn_resp' two times.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

linuxisgood wrote:

Another thing I discovered: Sending the 'sign_on' message two times to 328P (without pause in between) results in only ONE answer, the second request is ignored. When using the 32U4 you get two answers, as USB uses a buffer. Doesn't seem to matter when programming, so I don't know if it's intended or not (or an issue).

 

 

Yes, this happens because in Atmel's JTAGICE Mk2 protocol that situation can't happen. Avrdude never sends a burst of 2 commands, it sends one command then waits for the answer. So I didn't bother to implement a buffer for that possibility (and I'm not going to).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 32U4 port is working now (using Linux). I tried both timing from MegaAVR project and the bitbang timing. Both work fine.

Using the UART having Rx/Tx I connected the Tx via the resistor, Rx directly to the UPDI-pin as mentioned above.

The issue with Windows not initializing the COM port for transferring the sketch is not fixed, therefor it only works using Linux.

When programming the 32U4 the COM port changes - from COM3 to COM4 for doing the transfer, when using JTAG2UPDI it does not, but is not initialized, so the Arduino cannot send back the reply needed for UPDI to work.

 

I'm happy now being able to use the 32U4 for transferring the sketches, but for getting rid of Arduino dependencies (within 32U4) there is some work left. The Arduino library is used for initializing the USB. I also use their libraries for determining if a 32U4 is used.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe someone here has a clue about those USB issues? Personally, as I mentioned before, my knowledge of USB is vanishingly small :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The USB issue I created was just closed as not being related to Arduino-IDE. Well that may be true but won't help using Win users. I won't bother and use it using Linux ;-)

And I closed the issue I created for the 32U4 port.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

linuxisgood wrote:

The 32U4 port is working now (using Linux). I tried both timing from MegaAVR project and the bitbang timing. Both work fine.

Using the UART having Rx/Tx I connected the Tx via the resistor, Rx directly to the UPDI-pin as mentioned above.

The issue with Windows not initializing the COM port for transferring the sketch is not fixed, therefor it only works using Linux.

When programming the 32U4 the COM port changes - from COM3 to COM4 for doing the transfer, when using JTAG2UPDI it does not, but is not initialized, so the Arduino cannot send back the reply needed for UPDI to work.

 

I'm happy now being able to use the 32U4 for transferring the sketches, but for getting rid of Arduino dependencies (within 32U4) there is some work left. The Arduino library is used for initializing the USB. I also use their libraries for determining if a 32U4 is used.

 

I'm reading this with a lot of interest! I've created an account here just to reply ;)

 

I would be great to get this working on Windows as well because it would eliminate the need for an USB to serial chip, right? I've now build an UPDI programmer using and 328p and a FT231X.

 

@linuxisgood How are you getting along with this? I'd love to get in contact!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DustinWatts wrote:
@linuxisgood How are you getting along with this? I'd love to get in contact!

 

I can give you the link to linuxisgood's fork of jtag2updi:  https://github.com/haweiler/jtag2updi/tree/32U4_support

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

 

I can give you the link to linuxisgood's fork of jtag2updi:  https://github.com/haweiler/jtag2updi/tree/32U4_support

 

 

I'm already following that fork, thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I didn't have time the last to weeks to do the changes ElTangas wanted to be made. I hope to find time for that the next days to come.

Regarding 32U4 on windows: I had an issue created for the Arduino-IDE not allowing to program the 32U4 using windows.

But that issue was closed as not being an issue of Arduino-IDE rather than a windows issue.

 

If I get it right it is related to that those 32U4 devices get another COM port assigned when switching to program mode (from COM3 to COM4), not happening when using 328P devices.

When programming using Linux I couldn't see a change from ttyACM0 to ttyACM1 or alike.

The USB interface seems to allow handshaking simulating DTR/DSR and alike over USB which is not done using windows after changing to programming. But I haven't got a clue how to fix that. It's nothing to be handled withing jtag2updi as far as I can see.

I'd recommend to give Linux a try. Once you have it up and running it causes less problems as windows does I'd say as personal opinion.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!,

 

i'm new to the Attiny series with UPDI interface.
Currently i'm porting an older project to an Attiny1616 controller.
For programming i use jtag2updi with an Arduino Nano clone (self compiled). - Working great! (Big thanks to El Tangas!)
Unfortunately i've found a strange behavior. The sleep function of the avr is not working like expected.
I'm not getting under 2-3mA. To get it work i have to disconnect the programmer and connect it again. (Attiny powered from programmer)
Unless i do not execute any commands with avrdude it is working. As soon as i send a command, for example to get the avr id, current is back at 2-3mA permanently.
To get sure it is not a issue of my code i tried it with a clean project only within the sleep command. - Same problem

 

It seems the controller stays after the first command in a kind of programming / debuging mode.
Can someone confirm this problem?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RedSnake64 wrote:
It seems the controller stays after the first command in a kind of programming / debuging mode.

 

Maybe. It's been a while since I worked on updating jtag2updi, but it's possible I don't disable the UPDI unit on exit, I'll need to check.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
I'll need to check.

This would be great!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, UPDI is left running on exit. This clearly is not the best behaviour, so I'll fix it, probably during next week.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have fixed jtag2updi to turn the UPDI unit off on exiting a programming session. In case you happen to still be hanging around and read this, I would be grateful if you could do some power consumption tests using the new version.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sigh.  It's going to need a bunch of work before it'll program an AVR-DA  :-(

 

https://github.com/ElTangas/jtag...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah. I already looked at the new NVM implementation... why 'fix' what was working fine angry

I even have some AVR-DA for testing... eventually...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Sorry for the late response - Didn't get a notification sad

Now it is working! - Thank you very much!smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi !

I like your work very much and successfully programmed an Arduino nano using CH340 for use as UPDI-programer. 

 

Unfortunately programing the simple LED example to my Atmega4809 failed.
Here is my board: https://www.mikrocontroller.net/...

Pin D6 is connected with 4.7k to UPDI-Pin and also RST is connected via 470nF to VCC.

I used this line:

avrdude -v -v -p atmega4809 -c jtag2updi -P COM7 -U flash:w:Blink.ino.hex

Unfortunately this produced an error message:

avrdude: Can't find programmer id "jtag2updi".

In avrdude.conf is no entry for jtag2updi but there is "jtag2pdi".
Could you please tell me which avrdude.conf should I use getting rid to this?

Matthias

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where did you get that avrdude.conf? Clearly it's corrupted. You can use this one:  https://raw.githubusercontent.com/ElTangas/jtag2updi/master/avrdude.conf

 

This is the official repository:  https://github.com/ElTangas/jtag2updi

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
Where did you get that avrdude.conf?

 

I am not sure. In 2019 I tried building a newer WINAVR package because the old one was from 2010 and not capable for the Atmega4809. https://www.mikrocontroller.net/....

 

A newer AVRDUDE was needed. Therefore I searched at different sites and also had a look in different compiler packages.

 

Thank you very much - this helped !
I still try getting my first blink example on this Atmega4809 to run. I hope getting the problems solved soon.

 

Matthias

Pages