UPDI programmer software for Arduino - compatible with avrdude

Go To Last Post
166 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.

Pages