UPDI programmer software for Arduino - compatible with avrdude

Go To Last Post
199 posts / 0 new

Pages

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

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

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

A friend and I have developed a programmer, AVRgpp, which combines ISP programming, UPDI programming (with 12V pulse option) and USB-serial interface.  We decided to go over the top (why not, we're retired, now is the time to go OTT!) so it also has a two button/OLED human interface.  Everything, hardware and software, is open source but I have access to a web site so I have placed all the information there:

 

   https://wordcraft.com/avrgpp

 

Integrating a heavily edited version of ArduinoISP was straightforward but integrating jtag2updi into the menu system has defeated me - and I don't see the point reinventing the software wheel when El Tangas and Spence Konde have done all the excellent heavy lifting.  Obviously uploading jtag2updi to AVRgpp, without the human interface, works fine but it would be nice to have it menu-selectable like ISP and USB-serial.

 

We had a few PCBs made and my friend has built them up - I would be happy to put one in the mail for anyone who could help out.  For anyone interested there is a link to the current AVRgpp code on the web page here:  https://wordcraft.com/avrgpp#qsupdi

 

When we get it all working we will tweak the PCB (the buttons need moving slightly) and get a small batch of devices assembled.  We will post all files (including schematics, BOM and Gerber files) on the web page for anyone else who wants to get PCBs made or fully assembled units manufactured.

 

I appreciate that most people have a mountain of projects to keep up with but any help would be greatly appreciated.

 

Attachment(s): 

Started with three IBM 360/65s, moved up to 6502, got into "inventing, marketing and management", now returned to the interesting stuff.

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

trusty_mike, looks awesome  -- thanks for that

I've been off the AVR hobby for a few months.  Can't wait to get back and check this out.

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

Should anyone be interested, I wrote a protocol sniffer to dump the two-way dialog between AVRDUDE and jtag2updi and I enclose the annotated output as a text file.

 

The only mildly awkward bit was getting my sniffer to change speed (from 19200 to 115200) at exactly the same time as AVRDUDE and jtage2updi without losing any commands or responses.

 

I have also added an extra right angle three pin header to AVRgpp (between the two buttons) to bring out two unused data lines (PC1 and PC2) and Ground.  I set one up as a diagnostic software serial port to get stuff out of AVRgpp in the middle of the protocol to monitor what's going on..

 

I am working on an Arduino/IDE version of jtag2updi that uses the standard Serial (hardware) port between AVRDUDE and AVRgpp.  That bit works fine but I am not looking forward to the UPDI side of things!  Software serial can be used for single wire communications by switching the line between Tx and RX - I wrote some host and target test code between two Pro Minis and it worked fine.  However, software serial maxes out at 57600 for transmission.

 

Just to show how ancient I am, the sniffer is an edited version of a two channel terminal emulator I wrote in VB6  - which can still be edited and run under Windows 10!

Attachment(s): 

Started with three IBM 360/65s, moved up to 6502, got into "inventing, marketing and management", now returned to the interesting stuff.

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

trusley_mike wrote:
I wrote a protocol sniffer to dump the two-way dialog between AVRDUDE and jtag2updi and I enclose the annotated output as a text file.

 

You know avrdude does that if you pass verbose level 4 in the command line (-vvvv) right?

 

I assume you already have the documentation for the jtagice Mk II protocol and the UPDI protocol, but if you need any clarification regarding jtag2updi quirks you're welcome to ask.

 

trusley_mike wrote:
I am working on an Arduino/IDE version of jtag2updi that uses the standard Serial (hardware) port between AVRDUDE and AVRgpp. 

 

There is one adaptation already, called MuxTO, used in the Arduino nano Every  https://github.com/arduino/ArduinoCore-megaavr/tree/master/firmwares/MuxTO

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

El Tangas: many thanks for your very helpful message - and for all the hard work you have put in!  I didn't know about the extra AVRDUDE function - I shall have a look.  (But it was fun modifying my terminal emulator and the decoding and output format is under my control <g>)

 

I have the AVR067 JTAGICE mkII Comms Protocol and AVR060 JTAG ICE specifications.  I also have the UPDI stuff in datasheets for the ATtiny1614 and the ATtiny417 - because you mentioned the extra bit in the system status register.

 

I got a lot of info from your code and I wrote the sniffer to see exactly what AVRDUDE was using.  As you know, the real world rarely matches the theoretical one <g>

 

I am fortunate in targeting only one processor to run the code, ATmega328P, and one front end  AVRDUDE called from  the Arduino IDE.

 

I appreciate that I am not so much reinventing the wheel as reworking it so it looks more Arduino-ish rather than proper C-ish.  I will probably grind to a halt and tear my hair out!

 

I am dead chuffed with the extra pins that allow me to have a software serial debugging port for use within my code - a bit of an afterthought but we needed a new batch of PCBs to move the buttons so adding the header was straightforward.  My problem is that I only have to say "could we have ...?" to my electronics colleague and the next thing I know he has done the files and sent them of to China!  This means we tend to go through a lot of hardware iterations without a lot of deep though - but we do recycle parts with the help of a heat gun <g>

 

I should have new PCBs from China, and a couple of AVRgpps assembled, by the end of next week - would you like me to post you one?

Started with three IBM 360/65s, moved up to 6502, got into "inventing, marketing and management", now returned to the interesting stuff.

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

trusley_mike wrote:
I should have new PCBs from China, and a couple of AVRgpps assembled, by the end of next week - would you like me to post you one?

 

Sure, thanks, I'll pm my address.

 

From what I gather you are having trouble integrating jtag2updi in your product? I haven't looked at your code, but if I had to bet, the main point of contention will be the software serial that jtag2updi uses for the UPDI link.

This needs interrupts to be disabled, which will probably be a problem because the Arduino framework enables them for a variety of purposes. The software serial library from Arduino is just to slow to take advantage of the > 200 kbaud that UPDI can use.

 

I use this software serial for compatibility across the many AVRs that can run jtag2updi, but if I were to make a programmer where I have full control of the hardware that will run it, I would probably ditch the software serial and go for a MCU that has more than one USART instead of the mega328p (mega328pb maybe, or one of the mega AVR-0 like the mega4809).

 

This would make the Arduinification of jtag2updi much easier, you could just use one hardware serial to talk to avrdude, and another to talk to the target via UPDI. It would lead to another problem because UPDI is half-duplex, but still I think it's a lesser problem. Maybe.

 

There are Arduino cores for the mega328pb and the mega AVR-0 series (which are also UPDI chips that can be programmed with jtag2updi):

https://github.com/MCUdude/MiniCore

https://github.com/MCUdude/MegaCoreX

 

Also, everyone knows about the "Arduino as ISP" sktech, but this alternative was what actually inspired me to write jtag2updi:

https://github.com/microtherion/ScratchMonkey/tree/master/ScratchMonkey

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

El Tangas

 

Very many thanks for all that.  I will study more and take it all into consideration.

 

Personally I would sacrifice speed for simple code that made sense to Arduino-ists.  These processors have relatively small memory and small bootloaders and a few more seconds is no hardship.  It would be different if one was programming hundreds or thousands a day!

 

I really appreciate your comments and the more I look at things, the more I appreciate the work you have done!

 

An assembled PCB will be on the way ASAP - I may even laser cut an acrylic enclosure for it <g>

 

Started with three IBM 360/65s, moved up to 6502, got into "inventing, marketing and management", now returned to the interesting stuff.

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

Thanks to really helpful advice from El Tangas the jtag2updi code is now fully integrated into the AVRgpp firmware.

 

AVRgpp therefore offers menu-selected ISP and UPDI programming as well as straightforward USB-to-serial pass through.  3.3V or 5,0V power may optionally be applied to a target (within the limits of USB power) and a 12V pulse is available for UPDI programming if required.

 

An "In" as well as "Out" 6-way ISP header makes AVRgpp entirely "soft" so anyone may program it to do whatever they wish.  By default it would come with the Pro Mini bootloader and AVRgpp V0.1. firmware for ISP and UPDI programming.

 

Full details are on the web page:  https://wordcraft.com/avrgpp

 

Updated PCBs (with modified button locations and the three-way test port) are on the way from China.  The firmware and Eagle files should be available as soon as we have finished testing with the new boards and as soon as El Tangas has commented on the system I will send him.  Anyone is free to make populated or unpopulated PCBs from the files we provide - but I would be grateful if they would contact me first and I will provide them with a costed BOM.

 

If there is demand I may produce and sell PCBs, assembled units and enclosures.  Then again, I may not - I may move on to the next fun thing.

 

This has been a fun project (especially integrating jtag2updi!) and I am very grateful to those who have helped with useful advice.

 

Attachment(s): 

Started with three IBM 360/65s, moved up to 6502, got into "inventing, marketing and management", now returned to the interesting stuff.

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

New PCBs have arrived, units have been assembled and hardware development of AVRgpp is now complete.

 

More information is available on the updated web page:  https://wordcraft.com/avrgpp

Started with three IBM 360/65s, moved up to 6502, got into "inventing, marketing and management", now returned to the interesting stuff.

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

MikeDB1, (or anyone else);

 

Did you go forward with your plan to build an ESP8266 (or ESP32) version of the JTAG2UPDI?

 

I am asking because I built a LiPo powered ESP32 device for SPI programming which supports both programming over TCP from AVRdude and programming from the on-board FLASH storage of the ESP32. I use the TCP method during development and then I can take the device to the bench when I need to program lots of chips during assembly.

 

I need to update my current device or make a new one which supports UPDI for the newer microcontrollers.

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

Hey ElTangas,

Amazing work on the jtag2updi by the way. I have used that for almost a year now to program my atTiny.

Just wanted some ideas from you.
I'm looking to make the system standalone. This means not having a PC to send the code to a programmer over USB.

I have a hex code in an SD card (blink.ino.hex compiled for the atTiny). I want to connect the Arduino Uno/Nano/M0 to the SD card via SPI. Read the file that is there and flash the atTiny using UPDI.

Obviously the SD card interface was really easy. For the transfer, I was looking at BaldWisdoms BootDrive to get one board to program another. Problem is I'm not able to get support for the atTiny.

Any suggestions?

What do you think?

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

ChrisThomasNCA wrote:

Problem is I'm not able to get support for the atTiny.

Any suggestions?

What do you think?

 

Well BootDrive seems to send data to the target Arduino using the bootloader. So basically, it translates HEX file format -> STK500 protocol (which the bootloader expects and understands). OTOH, jtag2updi translates JTAGICE Mk2 protocol (sent by avrdude) -> UPDI (that the target tiny understands).

 

What you need is HEX ->UPDI so you need to take parts from both programs and make them work together. Not the easiest thing in the world, but not the hardest either. It will take some serious work that's for sure.

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

Hello,

 

As a hobby, I've been working with the jtag2updi software for about 6 months to allow use as a HV UPDI programmer running on the ATmega328P and other MCUs. Recently, after resolving UPDI enable issues with the ATtiny3216 (as target), the solution meant that I needed to use a more strict enable procedure. However, the solution means that for other ATtiny parts in the 0-1 series, it usually means programming twice for success. I think its similar to this issue.

 

This is what I'm using: Arduino 1.8.13, megaTinyCore 2.0.5, MPLAB X IDE v5.40, Saleae Logic Pro 8, Atmel Power Debugger, MPLAB Snap Debugger, Arduino Nano HV UPDI Programmer.

 

Investigating the UPDI baud rates (bit rates), these are the measurements I get:

 

Programmer Firmware Setting Initial UPDI Remaining UPDI
Nano HV Programmer jtag2updi 225,000 222,222 222,222
Atmel Power Debugger App 1.6.176, Tool 1.2.275 225,000 100,000 224,719
MPLAB Snap Debugger App 1.6.171, Tool 1.2.165 225,000 25,000 112,480

 

Note 1: The UPDI baud rate setting range for jtag2updi is 160,000 to 225,000. For the Power Debugger and Snap its 100,000 to 750,000

Note 2: Initial UPDI is the very first UPDI commands including Activation Key.

 

I find that the Power Debugger starts out at its minimum baud rate spec, then uses the user setting. The Snap debugger starts out at 1/4 its minimum baud rate spec, then uses a faster intermediate rate (not shown), then uses a faster rate that's 1/2 the user setting for the rest of the programming session.

 

Is it a requirement to use a slower initial UPDI baud rate? (I can't find any information on this anywhere)

Last Edited: Sun. Sep 27, 2020 - 06:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the 25000 baud of the Snap is a bug :/

225k is the maximum recommended baud at "default" settings.

Atmel tools typically start up at slower clock before raising the speed; maybe due to the legacy ISP/JTAG protocols...

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

Thanks, I didn't realize this characteristic was typical with their tools. Yeah, with the Snap its probably a bug, but well within the minimum 75 bps @ 4MHz UPDI default clock frequency.

Since I'm only focusing on initializing the UPDI, I'll write some test code to bit-blast the commands at 100K, 25K, 1K and 100 bps to see if there's any effect.

 

EDIT:

My UPDI initialization issue is resolved. I'm using F_CPU at 16MHz, so Minimum UPDI_BAUD = F_CPU/381 = 41,994. Therefore running tests at 100K or 50K was no problem. The problem was with the odd framing error I was getting when using the SYNCH character to enable the UPDI, which is required as the last part of the UPDI enable sequence. SYNCH, on its own, doesn't drive the signal high just prior to its start bit and just after the last stop bit, so I wrapped it with driving UPDI high on each end of the frame.

Last Edited: Tue. Sep 29, 2020 - 01:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi, i'm a hardware designer, i'm working on a project using Attiny414 & i have to do the coding part as well, i know how to write application code and other stuffs, but i'm clueless to upload the program into the chip, i don't have a any programmers, but i have arduino UNO, i tried to use arduino as ISP by reading articles in online, but while burning bootloader the arduino ide results an error and fails to burn,

my doubts are

1, whether the jtag2updi works only with arduino nano ??
2, do i need to upload the hex output generated from atmel studio or should i write my entire application in arduino ide

3, if i have to code in arduino uno, can i use the same code i written in atmel studio, in this case do i need to add any external files ??

 

vignesh

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

vignesh724452 wrote:

1, whether the jtag2updi works only with arduino nano ??

No, it works with Uno too. At least it should, I never actually tested.

 

vignesh724452 wrote:

2, do i need to upload the hex output generated from atmel studio or should i write my entire application in arduino ide

Either way should work. The requirement is that you must use avrdude for the upload, so if using Studio, it helps to setup avrdude as external tool.

 

vignesh724452 wrote:

3, if i have to code in arduino uno, can i use the same code i written in atmel studio, in this case do i need to add any external files ??

There is some kind of confusion here, the Uno is just to program the target tiny414, you don't write code for the Uno. If you use the Arduino IDE, you need to install the definitions for the tiny414 from here:

https://github.com/SpenceKonde/megaTinyCore

 

See instructions in this video:

https://youtu.be/AL9vK_xMt4E

 

Another similar vid for AVR-DA:

https://youtu.be/GpkUlP3u4bU

 

These guys use nano clones because they are more convenient, but just follow the same instructions using the Uno instead.

Last Edited: Sat. Nov 14, 2020 - 02:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

vignesh724452 wrote:

1, whether the jtag2updi works only with arduino nano ??

No, it works with Uno too. At least it should, I never actually tested.

 

vignesh724452 wrote:

2, do i need to upload the hex output generated from atmel studio or should i write my entire application in arduino ide

Either way should work. The requirement is that you must use avrdude for the upload, so if using Studio, it helps to setup avrdude as external tool.

 

vignesh724452 wrote:

3, if i have to code in arduino uno, can i use the same code i written in atmel studio, in this case do i need to add any external files ??

There is some kind of confusion here, the Uno is just to program the target tiny414, you don't write code for the Uno. If you use the Arduino IDE, you need to install the definitions for the tiny414 from here:

https://github.com/SpenceKonde/megaTinyCore

 

See instructions in this video:

https://youtu.be/AL9vK_xMt4E

 

Another similar vid for AVR-DA:

https://youtu.be/GpkUlP3u4bU

 

These guys use nano clones because they are more convenient, but just follow the same instructions using the Uno instead.


thank you for your reply @EL Tangas

vignesh

Pages