UPDI programmer software for Arduino - compatible with avrdude

Go To Last Post
247 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

As you may recall, I've been working on a UPDI programmer firmware to run on Arduinos (Arduini?), to facilitate the programming of the new xtiny MCUs. These chips are clearly gaining in popularity and maybe not everyone wants to invest in a Atmel-ICE, even with 50% discount.

 

The first version was for Atmel Studio but had several drawbacks, it was more of a prototype/hack. But now I have a new one, meant to be used with avrdude, that I think is a lot better.

 

You can get it here: https://github.com/ElTangas/jtag...

 

I hope it will be useful for low-budget hobbyists, it sure is useful to myself :)

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

Hey El Tangas,

 

I am trying to program an Attiny814 to blink an LED first before going to my intended program. But I have trouble understanding the tool (pardon me as I am a mechanical/automotive engineer) and it would be great if you could point me in the right direction. 

 

To successfully program an ATtiny814, I would need:

  • Atmel studio, to write the program, to tell which ports are outputs and high etc and then "build" the hex file
  • AVRDUDE: to burn the hex file into the ATtiny814 using Atmega 328P ( I have Arduino UNO )
  • Arduino to load your tool.

 

I understand the first 2 steps but I am having difficulties in understanding the last step on how to go upon using an Arduino UNO as a programmer. I saw few videos in Youtube on how to use Arduino as ISP but I am not sure how to use Arduino for this application. It would be great if you could help me out here!

 

Thank you!

---
Vish
An automotive engineer learning about uCs

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

You need to burn the programmer firmware into the Arduino. This is the "JTAG2UPDI.hex" file that you can find here: https://github.com/ElTangas/jtag...

 

You can do this using avrdude with a command like:

 

avrdude -p atmega328p -C {path}/avrdude.conf -c arduino -U flash:w:{path}/JTAG2UPDI.hex:i -P {COM port where arduino is connected}

(you need to supply the correct paths and COM port in your system)

 

Alternatively, if you have the Arduino IDE installed, you can follow these instructions:

 

Building with Arduino IDE

If you prefer, the program can be built as if it was an Arduino sketch. Inside the "source" directory, there is an empty file called "jtag2updi.ino" so that the Arduino IDE can recognize the source code.

Just copy all the files inside "source" to a new directory called "jtag2updi" inside your sketch main directory.

 In this case you just need to program the Arduino like you would any other sketch.

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

El Tangas wrote:

You need to burn the programmer firmware into the Arduino. This is the "JTAG2UPDI.hex" file that you can find here: https://github.com/ElTangas/jtag...

 

You can do this using avrdude with a command like:

 

avrdude -p atmega328p -C {path}/avrdude.conf -c arduino -U flash:w:{path}/JTAG2UPDI.hex:i -P {COM port where arduino is connected}

(you need to supply the correct paths and COM port in your system)

 

 

 

Aah yes. Dang. Thanks a lot. I would be following this method to flash the firmware. One more question. The hardware serial interface between the PC(avrdude) and the prograqmmer(Arduino UNO) is a normal USB 2.0 cable type A/B or should I use USB to Serial adapter? 

 

Thanks a lot for your help again!!

---
Vish
An automotive engineer learning about uCs

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

vishwar1 wrote:

 

The hardware serial interface between the PC(avrdude) and the prograqmmer(Arduino UNO) is a normal USB 2.0 cable type A/B or should I use USB to Serial adapter?

 

Any regular USB cable that fits to the Arduino will do, that is, you can use the same cable you use to burn the firmware.

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

El Tangas wrote:

vishwar1 wrote:

 

The hardware serial interface between the PC(avrdude) and the prograqmmer(Arduino UNO) is a normal USB 2.0 cable type A/B or should I use USB to Serial adapter?

 

 

Any regular USB cable that fits to the Arduino will do, that is, you can use the same cable you use to burn the firmware.

 

Awesome!! Thank you ! 

---
Vish
An automotive engineer learning about uCs

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

I just signed up to say thank you El Tangas! I've been interested about these new chips but thought it was a complete mission to program, but seems like you've done everything so you can use these chips in the Arduino environment. I'm just really really grateful, and wanted to say thank you for your commendable work! 

 

Let me get this straight, so if I take these steps I can pretty much use these chips as if they were an arduino? ie use adafruit libraries and program in a way I know and love? If so then dude, you're a damn legend, and why the heck is there only one other person to have cottoned on? You're a damn hero in my eyes and your praise deserves to be sung!!

 

Another question I have (I am a complete noob when comes to electronic circuit design, apart from badly designing a nano clone), if I was designing a circuit for one of these new attiny chips would I only need one exposed pin for UPDI programming? Is that what 1-wire means? If so then these chips are just bonkers cool, no blooming ICSP of FTDI headers on a board that take up so much space!

 

I've got an idea the for a board using these chips that the wearable crowd would eat for breakfast. So damn excited, sincerely thank you! 

 

 

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

hopCode wrote:
would I only need one exposed pin for UPDI programming?

Along with vcc and gnd and maybe reset? 

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

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

hopCode wrote:
Let me get this straight, so if I take these steps I can pretty much use these chips as if they were an arduino? ie use adafruit libraries and program in a way I know and love? If so then dude, you're a damn legend, and why the heck is there only one other person to have cottoned on? You're a damn hero in my eyes and your praise deserves to be sung!!

 

Whoa, whoa, not so fast! These chips are quite different from previous mega and tiny, and more similar to xmega. I can't guarantee library compatibility, that's the job of the library writers.

Maybe when the new Arduino based on the Atmega4809 (which is an UPDI chip), is out, all the stuff you mentioned will eventually become possible.

Right now, you can't, in general, use them as an Arduino.

 

I made this program for people who use Atmel Studio, not the Arduino IDE. I used the Arduino hardware as platform for the programmer, because it's cheap (I mean, the Chinese clones) and easily available.

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

ok ok I'll slow down haha! I have read these chips are some sort of PIC and Attiny hybrid, and their name is somewhat confusing to most. I'm more familiar with that normal Arduino IDE, I think I may bite the bullet and jump into Atmel studio and see what happens (unless you have to pay for the software; then I'm Tom Tuggered). 

 

If i'm completely honest what I really wanna build is the simplest WS2812b driver, with only a few components, that I hopefully can be lazy and just program in the way I know and love. I had hoped these new chips could be up to the challenge. 

 

I may give this new Attiny stuff a try anyway and see what happens, do what I usually do test things, break things, hack things, hopefully learn something along the way. Price point is pretty compelling! 

 

I can't use them as an Arduino, maybe a better question is can I slap some C code on these new Attiny's and hack/find or blag someone elses WS2812 library to control some LEDs?

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

The tight code requirements of the WS2812B IC   (8 bits each for red:green:blue, a logic 0 being high for 0.4 microseconds and low for 0.8 uS and a logic 1 being high for 0.8uS and low for 0.4uS) requires in-line assembler.   The internal op-codes of the UPDI IC MAY be different enough to require a rewrite of the most-commonly used Arduino code for the WS2812B "NeoPixels".

 

Now that Arduino is the world standard for low-cost custom-application AVR development, it should be the microcontroller IC makers who adapt their new IC models to Arduino. They should offer their new IC models for sale on tiny module boards with the Arduino boot-loader pre-installed at low-cost like the $3 Arduino Nanos currently available on eBay.

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

Thanks for the comment! Eek well if it requires a re-write that could be an interesting learning curve. I've stumbled over a fair few tutorials on the timing, although I don't think I would take the gamble on whether I can savant it up and turn it into assembler frown

 

I fully and holeheartedly agree with that sentiment*, I wonder if these companies make enough money to employ people to do a job like that, if so where do I sign up? 

 

*My confusion comes in the form of I thought Atmel was synonymous with Arduino, and at one stage thought all Atmel chips could be programmed through or is if they were an Arduino.

 

EDIT: I think it could be worth noting the new datasheets for current WS2812b say reset of >280uS, supports lower frequency and inexpensive MCU. (http://www.world-semi.com/Certif...)

Last Edited: Tue. Jun 5, 2018 - 01:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

hopCode wrote:
or is if they were an Arduino.
Not really. See this table:

 

https://en.wikipedia.org/wiki/Li...

 

Specifically the "Processor" column - *those* are the "Arduino processors". In the 8bit AVR range that basically means ATmega32U4, ATmega328P, ATmega2560, ATmega168. The Arduino installation has "core" support for each of those. (so implementations of things like digitalWrite(), analogRead(), Serial.begin(), etc that work with those specific models). For the Arduino system to support a different micro it needs a new "core" added. Some people have developed these for other models of AVR:

 

https://playground.arduino.cc/Ma...

 

So for other chips you might find it listed there - in which case you'd follow the associated link, download the additional core and add to your Arduino installation - then it should be able to support that added chip. But that's still just a tiny subset of the 300+ models of AVR that there are. I don't know if anyone has yet looked at doing this for "Xtiny" (which is what these new, UPDI based AVRs based on the Xmega range are generically referred to as).

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

clawson wrote:
I don't know if anyone has yet looked at doing this for "Xtiny" (which is what these new, UPDI based AVRs based on the Xmega range are generically referred to as).

 

Well someone seems to have done it for the Xmega range: https://github.com/XMegaForArdui...

 

With a few tweaks I wonder if it could be made to include the new Tiny's as well, if your statement is correct and they are based on the xmega range, and not actually some other miscreant hybrid.

I should probably start a thread, I feel really bad shoe horning in here. Apologies, and thank you all for the healthy responses, this place seems cool, I'll stick around!!

 

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

It's better to wait for this one: https://store.arduino.cc/usa/ard...

Supposedly, the "brand new 8-bit microprocessor from Microchip" will be the atmega4809, which is an UPDI chip, therefore, someone must be undertaking the rather difficult work of writing the required Arduino libraries.

Once the libs for the atmega4809 are available, adapting them to the other "xtinies" should not be so hard.

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

Hello,

 

I was able to flash chips while using an Arduino Uno but tried switching over to a Arduino Pro Mini 3V3 and had no luck. If I can flash the jtag2updi code onto the 328p the rest should work the same, right? I tried connecting my sparkfun FTDI to the mini with DTR pin broken off and I can see the my serial TX line sending logic but pin 6 doesnt show any activity on my Saleae...

 

@El Tangas, do you have any additional instructions?

 

Ps. This application is great! Thank you! 

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

The 3.3V pro mini runs @8MHz, right? My software requires 16MHz to run. This is because of the software UART I implemented for the UPDI link. It may work @8MHz with a few changes but I wouldn't bet on it, the timing is a bit tight.

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

Ok, after further consideration, I see that since the mega328p is not specified to run at 16MHz with a 3.3V VCC, this is a problem when programming at lower voltages.

I will try to modify the code to also run at lower speeds, selectable at compile time using F_CPU. This might take a while though.

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

Hey, thanks for the speedy reply.

 

I was hoping to use a 3.3V board to avoid needing to disconnect my other 3.3V circuitry when flashing with my Uno but good to know. Im glad I asked! I can probably just go back to an Uno or get a logic converter for now. Maybe if Im lucky, Ill have time to fix it myself ;)

 

Might be good to specify the 5V in the README.md next time you push an update, since you already mention Arduino Mini Pro.

 

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

In case you are still around, I have updated jtag2updi so that it can run at speeds other than 16MHz. I would be grateful if you could test it with your 3.3V Arduino, I ran some tests using a Mega328P running @8MHz from the internal oscillator.

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

I gave it shot but no luck. It looks like Im getting the beginning sync byte but no response. 

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

 

El Tangas:

 

Thank you for making this software. I have it running on an unmodified Seeeduino v4.2 set to 3.3v (a bargain at $US6.90). Works great.

 

For reference, here is the command line I am using to program my ATtiny412:

avrdude.exe -c jtag2updi -P com5 -p t412 -e -U flash:w:Tiny412Blink.hex

I do have a question about programming the fuses though.

 

I can get the example fuse code for the AVRTiny to compile, but the fuses do not seem to get set in the device. In particular, I am trying to take over the uPDI/RST pin as GPIO, and I can tell the fuse must not be getting set, because I can still reprogram the chip :-)

#if 1 // !! BRICK_THIS_CHIP !!
// Set the fuse so the uPDI will be a GPIO.
// This will make the chip unable to be reprogrammed
// until a 12v pulse is applied. Eeek!
// Apparently this structure needs to be packed from
// the start, but not the end (?)
FUSES =
  {
  //Watchdog Configuration (default is 0x00)
  .WDTCFG=WINDOW_OFF_gc | PERIOD_OFF_gc,
  //BOD Configuration (default is 0x00)
  .BODCFG=0x00,
  //Oscillator Configuration (default is 0x02)
  .OSCCFG=FREQSEL_20MHZ_gc,
  //Apparently need for the compiler.
  .reserved_0x03=0x00,
  //TCD0 Configuration (default is 0x00)
  .TCD0CFG = 0x00,
  //System Configuration 0 (default is 0xC4)
  //Be aware, this breaks future programming
  //unless you use a 12v pulse to reset
  .SYSCFG0 = CRCSRC_NOCRC_gc| RSTPINCFG_GPIO_gc,
  //System Configuration 1 (default is 0x07)
  .SYSCFG1 = SUT_64MS_gc,
  //Application Code Section End (default is 0x00)
  .APPEND = 0x00,
  //Boot Section End (default is 0x00)
  .BOOTEND = 0x00,
  };
#endif

Is this programming firmware supposed to be able to program the fuses?

 

Is there some fiddly bits needed to make fuse programming work?

 

Thanks for any assistance you can offer.

 

TinyAVR Fuse uPDI Programming ATtiny212 ATtiny214 ATtiny412 ATtiny414 ATtiny416 ATtiny417 ATtiny814 ATtiny816 ATtiny817 ATtiny1614 ATtiny1616 ATtiny1617

Last Edited: Tue. Sep 11, 2018 - 06:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some more information this morning: I compared my hex file with and without the code above included. They are identical, so I do not think the fuse information is making it to the programmer. Studying that now.

. . . 

OK, it appears that AVRDUDE needs the fuses passed to it on the command line. The examples I am finding only have three fuse bytes. As far as I can tell the ATtiny412 has 8 (9 with reserved) fuse bytes. Still looking.

 

Last Edited: Tue. Sep 11, 2018 - 02:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fuse info is NEVER in the .hex file (only microchip do that with PICs - it's never been the case for AVR).

 

You can only use .fuse section programming if you use ELF not HEX files (because ELF are multi-section and as well as .text+.data for the flash image and .eeprom for the EEPROM, they can have .fuses for the fuses and .lock for the lockbits),

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

clawson: Thanks for confirming that the fuses are not in the HEX.

 

I am looking now to see if/how El Tangas's programmer in conjunction with AVRDude can be used with ELF files.

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

-- THIS WILL BRICK YOUR ATtiny412 CHIP --

(well, only until you use a 12v pulse to get around it)

 

Here is the information to write the RSTPINCFG_GPIO_gc fuse to an ATtiny412 using El Tangas's jtag2updi  programmer.

 

This will change the RST/uPDI pin (permanently) to a GPIO which your code can control.

 

This also shows how AVRDude can be used with ELF files.

 

In your source:

#if 1 // !! BRICK_THIS_CHIP !!
// Set the fuse so the uPDI will be a GPIO.
// This will make the chip unable to be reprogrammed
// until a 12v pulse is applied. Eeek!
// Apparently this structure needs to be packed from
// the start, but not the end (?)
FUSES =
  {
  //Watchdog Configuration (default is 0x00)
  .WDTCFG=WINDOW_OFF_gc | PERIOD_OFF_gc,
  //BOD Configuration (default is 0x00)
  .BODCFG=0x00,
  //Oscillator Configuration (default is 0x02)
  .OSCCFG=FREQSEL_20MHZ_gc,
  //Apparently need for the compiler.
  .reserved_0x03=0x00,
  //TCD0 Configuration (default is 0x00)
  .TCD0CFG = 0x00,
  //System Configuration 0 (default is 0xC4)
  //Be aware, this breaks future programming
  //unless you use a 12v pulse to reset
  .SYSCFG0 = CRCSRC_NOCRC_gc| RSTPINCFG_GPIO_gc,
  //System Configuration 1 (default is 0x07)
  .SYSCFG1 = SUT_64MS_gc,
  //Application Code Section End (default is 0x00)
  .APPEND = 0x00,
  //Boot Section End (default is 0x00)
  .BOOTEND = 0x00,
  };
#endif

Command line for AVRDUDE to set FUSES on ATtiny412 using ELF file:

avrdude.exe -c jtag2updi -P com5 -p t412 -e -u -U flash:w:w:YourProject.elf:e -U fuse5:w:YourProject.elf:e

* I have verified that I can manually use a bench supply to jam 12v into the uPDI pin to enable further programming. You will want to protect your circuitry that is connected to uPDI from the 12v. I used a 1K resistor figuring that it would limit the current driven into my circuit to ~ 9mA (12v-3.3v)/1K

 

Bonus: I do not think I have fried anything . . . yet!

 

tinyAVR uPDI RST GPIO ATtiny212 ATtiny214 ATtiny412 ATtiny414 ATtiny416 ATtiny417 ATtiny814 ATtiny816 ATtiny817 ATtiny1614 ATtiny1616 ATtiny1617

Last Edited: Thu. Sep 13, 2018 - 03:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm glad everything worked out. As you learned, hex files can only hold data for one memory type, unlike elf files that have multiple sections and therefore can hold the data for all the different memories.

So your question was more of a general avrdude/object file format question than something specifically related to my program.

 

I also want to note that if you do some calculations from the Mega328P datasheet, the maximum operating frequency at 3.3V is 13.3MHz, so the Seeeduino operating @ 16MHz is a bit overclocked (+20%) when running at 3.3V.

 

edit: yeah, I believe someone here had already tried to give a 12V jolt to the UPDI pin an was also able to get it into programming mode. Maybe it would be better to limit the current from the 12V source to 1mA or less, so as not to strain the protection diodes in your main circuit.

 

edit2:

  //Apparently need for the compiler.
  .reserved_0x03=0x00,

Actually, this fuse seems to be unused. It's factory value is 0xFF, but you can put any value there and it doesn't seem to have any effect.

Last Edited: Tue. Sep 11, 2018 - 08:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can I use this method to program the Mega4809 or is it not supported? I've been tinkering with a project on the xplained pro dev board and am wondering if I can use this to program the 4809 on a standalone PCB? I can't really justify the purchase of an Atmel-Ice at the moment... When I purchased this I was unaware of the different programming requirements and mistakenly thought I could use my cheap AVR Pocket Programmer.

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

dino_cupertino wrote:
... and am wondering if I can use this to program the 4809 on a standalone PCB?
Yes

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

 

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

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

gchapman wrote:

dino_cupertino wrote:
... and am wondering if I can use this to program the 4809 on a standalone PCB?
Yes

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

 

 

Fantastic! Thank you sir!

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

You can, in principle, program any UPDI chip defined in the avrdude.conf file I supply. The complete list is:

 

# ATtiny202
# ATtiny204
# ATtiny402
# ATtiny404
# ATtiny406
# ATtiny804
# ATtiny806
# ATtiny807
# ATtiny1604
# ATtiny1606
# ATtiny1607
# ATtiny212
# ATtiny214
# ATtiny412
# ATtiny414
# ATtiny416
# ATtiny417
# ATtiny814
# ATtiny816
# ATtiny817
# ATtiny1614
# ATtiny1616
# ATtiny1617
# ATtiny3214
# ATtiny3216
# ATtiny3217
# ATmega3208
# ATmega3209
# ATmega4808
# ATmega4809

 

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

I got it blinking! Thank you for your work on this El Tangas! 

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

hey, I have read all the data in the chat above but being new to this field I couldn't understand it. I have attiny406 uC and USBASP programmer and an Arduino mega. I have generated a hex file using Atmel studio. I also have winAVR and Arduino ide installed in my pc. Can someone explain me the steps to flash my program in the IC?

 

Thanx in advance.

Last Edited: Sat. Oct 6, 2018 - 07:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can try to help, but my software is not meant for Arduino Mega. It will need to be ported, it should not be very difficult because the ATMega2560 in the Arduino Mega has similar peripherals to the Mega328P on the Arduino uno.

However I will need your cooperation since I don't have an Arduino Mega for testing.

So, first, I need to update the jtag2updi repository, I have some changes that need to be done.

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

No problem with arduino mega, if it is easily possible with usbasp module, we can use that also. I have a usbasp module

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

No, usbasp can't be used to program the tiny406.

 

Ok, the first thing you need to do, is create a sketch called "jtag2updi" then copy from my repository, the files inside the "source" directory to the sketch directory.

Then open the sketch in the Arduino IDE, change the preferences to display detailed compilation info, select the arduino Mega and hit the verify button. There will be errors, please copy and post here.

Last Edited: Sat. Oct 6, 2018 - 03:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!

 

I have some troubles with the jtag2updi. I have program an Arduino Nano v3 and I've disallowed the reset by DRT (unsoldering the capacitor), but in my scope I don't see any signal in the PIN D6 when I use the avrdude command (COM13):

avrdude -c jtag2updi -P com13 -p t412

I get this error from avrdude:

avrdude: jtagmkII_getsync(): sign-on command: status -1

As I said, I don't see anything in my scope, and it is very very strange.

 

I've tried changing the serial speed, but without success. Also, I've programed a simple script for test the PORT D6, and it works perfectly.

 

The hardware configuration is very simple, an Arduino Nano v3 (without the capacitor for DRT reset) plus a 4,7KOhm resistence between D6 and the UPID pin (pin 6 for the ATtiny412). I get the power from the arduino +5 and GND pins.

 

Could you help me?

 

Thank you! 

 

P.S. Now I'm in a trip, but this weekend I can do some test if you need more information.

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

Ok. The first thing that comes to mind is that maybe the nano has a Mega168 instead of a mega328P. The precompiled binaries are for the 328P and won't work on a 168.

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

It has the mega328p. I tried with the compiled version and my own compilation with Arduino IDE 1.8.5 and I was able to flash it without problems (I specified the microcontroller, boot version and serial port in the Arduino IDE settings).

 

I remember that at the begining, after reset or power on the LED (PB5) blinked for 3 times, is it correct? 

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

Elektor has published a news article about your programmer : "UPDI programmer for ATmega4809 and ATtiny816/817" !

Bernard.

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

I may have introduced some bug... people have forked older versions, please try them out.

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

El Tangas wrote:

I may have introduced some bug... people have forked older versions, please try them out.

Ok, I will try them the weekend. Any suggested version?

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

WeSo wrote:
I tried with the compiled version and my own compilation with Arduino IDE 1.8.5 and I was able to flash it without problems

 

Well, I just flashed the current version of jtag2updi on an Arduino nano, either compiled with AS7 or Arduino IDE 1.8.2 and it seems to be working fine with tiny1614 and tiny1616 (that's what I can test right now).

I disabled the reset function using a 10uF capacitor from RST to GND.

 

 

 

pradines wrote:
Elektor has published a news article about your programmer : "UPDI programmer for ATmega4809 and ATtiny816/817" !

 

Cool. I had already noticed lots of traffic coming from Elektor to the jtag2updi repository.

Last Edited: Tue. Nov 20, 2018 - 10:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

WeSo wrote:

I tried with the compiled version and my own compilation with Arduino IDE 1.8.5 and I was able to flash it without problems

 

 

Well, I just flashed the current version of jtag2updi on an Arduino nano, either compiled with AS7 or Arduino IDE 1.8.2 and it seems to be working fine with tiny1614 and tiny1616 (that's what I can test right now).

I disabled the reset function using a 10uF capacitor from RST to GND.

 

Some questions:

- Is the version v3?

- The led blink 3 times? Maybe my Nano is being reset for some reason...

- Can you monitor the D6 output with a scope?

 

I disabled the reset function with two options:

- 120Ohm resistor from RST to +5

- Removing the capacitor in RESET pin. This one worked because now for re-flash the Nano I have to press the button.

 

I will try with other Nano. I don't remember if I ordered tiny161x.

 

Thank you for all!

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

WeSo wrote:

Some questions:

- Is the version v3?

- The led blink 3 times? Maybe my Nano is being reset for some reason...

- Can you monitor the D6 output with a scope?

 

  • The Nano is a generic Chinese clone from Ebay/Aliexpress
  • The LED is not supposed to blink 3 times. It should just stay on while the UPDI is in programming mode.
  • The D6 signal looks like this, when probed on the UPDI side (after the resistor):

 

 

Notice that the UPDI while on input mode has a pull-up resistor, this causes the signals from the host to not go fully to GND (the 4.7k resistor forms a voltage divider with the pull-up). The signals sent by the UPDI side go to GND.

This is useful for diagnostic, allowing us to see on the scope which side is "talking". Each data packet sent by the host starts with a synch signal (4 periods of square wave) visible on this sample.

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

El Tangas wrote:

WeSo wrote:

 

Some questions:

- Is the version v3?

- The led blink 3 times? Maybe my Nano is being reset for some reason...

- Can you monitor the D6 output with a scope?

 

  • The Nano is a generic Chinese clone from Ebay/Aliexpress
  • The LED is not supposed to blink 3 times. It should just stay on while the UPDI is in programming mode.
  • The D6 signal looks like this, when probed on the UPDI side (after the resistor):

 

 

Notice that the UPDI while on input mode has a pull-up resistor, this causes the signals from the host to not go fully to GND (the 4.7k resistor forms a voltage divider with the pull-up). The signals sent by the UPDI side go to GND.

This is useful for diagnostic, allowing us to see on the scope which side is "talking". Each data packet sent by the host starts with a synch signal (4 periods of square wave) visible on this sample.

I use a chinese clone too :\ I will try other unit, but it works perfect with other programs.

 

I get 3 blinks at boot... very strange.

 

I suppose that even without a microcontroller connected, I should see in my scope the initial pattern, right?

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

The first thing you should see in the UPDI line is the "double break" pattern, that is, two consecutive low pulses of 24.6 ms each. See the first scope trace in this post: https://www.avrfreaks.net/forum/...

 

Note that jtag2updi will usually enter infinite loops when things go wrong (yeah, in my laziness I haven't implemented timeouts in the program yet).

So, you should always reset the Nano in the event of failure, then try again.

 

Also, avrdude can output useful diagnostics if you add the -v option to the command line. You can use up to 4 -v (that is, -v -v -v -v) to get more and more diagnostic info.

This will show the avrdude step at which failure occurs.

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

Yes, I tried the -vvvv output, then I saw that it fails waiting the reply, I mean, avrdude sent the first pattern but it didn't receive the response. Meanwhile, I didn't see anything in my scope.

 

This weekend I will test with other hardware and I will monitor the reset pin and others... I'll keep you informed.

 

Thank you El Tangas!

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

Hi!

 

I have tried with other Nano v3 and it works perfect now... I don't know why the other model does not work :(

 

Work vs not work

 

Thank you for all El Tangas!

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

Strange... which one is working, the blue one or the black one?

 

I'm guessing the blue one works? It's modded with a cap on RST to GND, while on your first post you said you used a different mod, so the original must be the black one.

 

Well, the important thing is that you got it workingyes, I like the way you took advantage of the programming header of the nano to build your programmer, thanks for the pic.

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

El Tangas wrote:

Strange... which one is working, the blue one or the black one?

 

I'm guessing the blue one works? It's modded with a cap on RST to GND, while on your first post you said you used a different mod, so the original must be the black one.

 

Well, the important thing is that you got it workingyes, I like the way you took advantage of the programming header of the nano to build your programmer, thanks for the pic.

Yep, the blue is working.

The black is after remove all extra components. With the same assembly, even the cap on RST to GND, it does not work. I don't know whyindecision

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

Hi El Tangas, 

I've just been trying to flash the source onto a Mega2560 via Arduino IDE. When it tries to compile, it spits an error for sys.cpp that "PRR" was not declared in the scope. 

Any ideas? 

Bevan 

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

This program is only compatible with Mega328P and other chips of the same AVR sub-family (i.e. Mega48/88/168).

I can't guarantee it will work with Mega2560, but you can do this:

 

Edit file sys.cpp and remove the following code:

	/* Disable unused peripherals */
	ACSR = 1 << ACD;		// turn off comparator
	PRR =
		(1 << PRTWI) |		// turn off 2 wire interface
		(1 << PRTIM2) |		// turn off timer 2
		(1 << PRTIM1) |		// turn off timer 1
		(1 << PRSPI) |		// turn off SPI interface
		(1 << PRADC);		// turn off the ADC

Then, rebuild and upload with the Arduino IDE. I _think_ it will compile OK, but will still not work, because the code needs to be modified in other files too, most notably updi_io.cpp.

 

The problem is, I use the OC0A pin for the UPDI interface. On the Arduino Mega, this is connected to an LED that will mess up communications. So, updi_io.cpp needs to be modified to use OC0B instead, which will be more or less hard depending on your experience with AVR programming.

 

I've been tweaking the code to make it easier to port, but it's not quite there yet... At least, I have confined most hardware specific code to these files, sys.cpp, updi_io.cpp and JICE_io.cpp.

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

I am having issues with the error avrdude: jtagmkII_getsync(): sign-on command: status -1

 

I have everything configured correctly as far as i can tell, and from reading the thread here.

 

I used a 120 ohm resistor from reset to 5v, i have a 4.7kohm resistor from Pin 6 on my arduino uno to reset/UPDI pin on my attiny404

 

I tried 2 versions of the firmware on my uno that were suggested above.

 

my bat file runs this command: avrdude -c jtag2updi -P com1 -p t404 in the folder with avrdude.exe and the .config file from the downloaded jtag2updi-master file located in the C:\Users\Luke\Documents\jtag2updi-master

 

I am looking at the pin with my scope and am not seeing any activity on pin6.

 

any ideas?

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

ssmithl379327 wrote:
I used a 120 ohm resistor from reset to 5v

That seems like a really really really strong pull up, have you tried a 10k?

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

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

Isn't the 120 from reset to 5v on the Arduino meant to disable the reset? isn't that its purpose?

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

ssmithl379327 wrote:
Isn't the 120 from reset to 5v on the Arduino meant to disable the reset

Show me an Arduino with a 120 ohm reset pull up???

 

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

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

Its not a standard pullup, in the readme of the jtag2updi-master, to make this programmer work requires disabling the auto restart feature of the arduino.

 

https://github.com/unforgiven512...

 

Download it and have a read.

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

ssmithl379327 wrote:
I am looking at the pin with my scope and am not seeing any activity on pin6.  

 

That's the same thing the poster in #37 said. No signal on pin 6. He tried a different Arduino and then it worked... I can't figure it out, because I'm not able to reproduce this. All the Arduinos I tested work ok.

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

I misunderstood, this was on the programmer AVR reset pin. 

Thanks for the link.

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

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

I just got it to work, not sure what the issue was. I unplugged the Arduino and re plugged it in ans walla!

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

Good. Sometimes, you need to reset the programmer, it can get stuck in an infinite loop under certain conditions (especially communications failure with the UPDI interface). I need to fix that, one day...

 

edit: so basically, don't send avrdude commands if the target MCU is not powered or connected to the programmer. It will probably hang.

Last Edited: Wed. Dec 12, 2018 - 10:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quick Question, how do i set fuses now? I am having issues getting my ATTINY404 to run at 20MHz, its defaulting to the 20Mhz but the prescaler defaults to x6, So all i get is 3.3Mhz. I usually do it though atmel studio7.

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

You set the fuses by using the FUSES macro, like this:

FUSES = {
    .WDTCFG     = WINDOW_OFF_gc | PERIOD_OFF_gc,
    .BODCFG     = LVL_BODLEVEL7_gc | SAMPFREQ_1KHZ_gc | ACTIVE_ENABLED_gc | SLEEP_SAMPLED_gc,
    .OSCCFG     = FREQSEL_20MHZ_gc,
//  .TCD0CFG	=
//  .SYSCFG0	=
//  .SYSCFG1	=
//  .APPEND     =
//  .BOOTEND	=
};

 

Be careful, all fuses not explicitly set will be filled with zero and this can brick your ATtiny. Be sure to set the UPDI pin to UPDI mode. To upload, you can extract the fuse section from the elf file to a hex binary file like this:

 

avr-objcopy -j .fuse input_file.elf -O ihex binary fuses.hexbin

 

Then use avrdude to write the fuses.bin file to the MCU fuse memory.

 

You can only choose 20MHz or 16MHz via fuses. The CPU clock divisor is set by software.

Last Edited: Thu. Dec 13, 2018 - 01:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is my code, still is not running at 20MHz, any ideas?

 

#include <avr/io.h>
#define F_CPU 20000000L
#include <util/delay.h>

#define sbi(x, y) x |= _BV(y)                // set bit - using bitwise OR operator
#define cbi(x, y) x &= ~(_BV(y))             // clear bit - using bitwise AND operator
#define tbi(x, y) x ^= _BV(y)                // toggle bit - using bitwise XOR operator
#define is_high(x, y) (x & _BV(y) == _BV(y)) // check if the y'th bit of register 'x' is high

int main(void)
{
    CLKCTRL_MCLKLOCK = 0x00; // Unlock clock registers
    CLKCTRL_MCLKCTRLA = 0x00; //Set clock to the internal 20MHz oscillator
    CLKCTRL_MCLKCTRLB = 0x00; //Set No Prescaler on clock
    
    
    PORTA_DIR = 0xff; //Set PORTA to Output
    PORTB_DIR = 0x00; //Set PORTB to Input
    
    while (1)
    {

        _delay_ms(500);
        PORTA_OUT = 0xff;
        _delay_ms(500);
        PORTA_OUT = 0x00;

    }
}

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

Yeah, if you look at the datasheet, you will notice that those registers have the "Configuration Change Protection" property. This means there is a special procedure to write to them.

There is a macro you can use, like in this example:

 

void clock_init(void){
	_PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_10X_gc | CLKCTRL_PEN_bm);
}

 

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

Thanks so much! I am a bit of an AVR noob.

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

No problem, these chips are new so this kind of information is not easy to find unless you already know where to look.

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

baxsie wrote:
* I have verified that I can manually use a bench supply to jam 12v into the uPDI pin to enable further programming. You will want to protect your circuitry that is connected to uPDI from the 12v. I used a 1K resistor figuring that it would limit the current driven into my circuit to ~ 9mA (12v-3.3v)/1K

 

Is there a magical procedure for this? On a 412 I set the UPDI pin to be GPIO and can't figure out how to change it back.  Using avrdude and the jtag2updi programmer always fails with this

 

avrdude: jtagmkII_recv(): Got message seqno 6 (command_sequence == 6)
avrdude: Recv: . [80]

Raw message:
0x80
OK

avrdude: jtagmkII_reset(): Sending reset command:
avrdude: jtagmkII_send(): sending 2 bytes
avrdude: Send: . [1b] . [07] . [00] . [02] . [00] . [00] . [00] . [0e] . [0b] . [01] . [f6] h [68]
avrdude: jtagmkII_recv():
avrdude: ser_recv(): programmer is not responding
avrdude: jtagmkII_recv(): Timeout receiving packet

avrdude: jtagmkII_reset(): timeout/error communicating with programmer (status -1)
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

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

I never tested it, but in theory you need to apply 12V to the UPDI pin (it needs to be disconnected from the programmer and anything else that might get damaged by 12V).

This will put the pin in UPDI mode until the next power cycle.

So, without disconnecting the target MCU from the power supply, remove the 12V source and reconnect the programmer, it should work (untested by me). You may need to reset or power cycle the programmer.

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

That's exactly what I did. After applying the 12v to the pin I can see on my scope that it is no longer a GPIO pin (it outputs a pulse 1/sec while in GPIO), also a power cycle puts it back to being GPIO. The programmer does start communicating with the 412, but always fails when it tries to do "Sending reset command".

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

That reset is the first time the UPDI interface is actually used, the previous commands are just an exchange of miscellaneous information between avrdude and the programmer.

So that error means the UPDI link is not working, to be honest I don't know why. Have you tried to reset/power cycle the programmer to see if it decides to start talking to the UPDI interface?

 

That is:

 

1) Disconnect programmer

2) Pulse 12V on UPDI pin

3) Connect programmer

4) use avrdude

5) if fail reset programmer then goto 4)

6) If you have repeated the above steps a few times without success, sorry.

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

Thanks for the response El Tangas. Unfortunately that exactly what I have tried many times without success.

Having done some digging it is never getting a response from the target when it requests the ASI_SYS_STATUS value when trying to enter progmode. I have checked it on a scope and I see the SYNC and the LCDS instruction, but there is never a response. The programmer doesn't deal with this well and goes into an infinite loop waiting for PD6 to go low, which it never does.

 

I have no idea why the target isn't responding. The 12V pulse has put it into UPDI mode as it succeeds doing the enable UPDI part.

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

Can you see the double break? These are 2 long low pulses of 24.6ms each. They are needed to initialize the UPDI and should come before the first UPDI command, which is SYNCH/STCS REG2, 0x06   (0x55, 0xC2, 0x06).

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

Yes I see those. Both are 24.6mS with a 2mS high signal between them, followed by the the SYNCH/STCS.

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

Today I etched a new carrier board and mounted a new ATTiny412 so I could plug it into a breadboard. With this fresh chip the programmer works. I suspect there is something about the 12V activation that Microchip aren't telling us in the datasheet. I am wondering if you have to apply the 12V within that 8.8mS timeout after POR, but I have no easy way to test this. For now I am switching to a device where the XDIR pin (that also not documented in the data sheet) is available on something other than the UPDI pin.

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

Hey, I never noticed that XDIR pin. Does it enables/disables the USART transmitter? Do you have any info?

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

Yes it is available on the T412 on the UPDI pin. When you configure the serial port to be External RS485 and fuse the UPDI as GPIO and then set it to be an output the USART automatically manages it for you to control an external driver. I am still waiting to find out what Internal mode is.

 

I found this out when I queried Microchip about some weird behaviour on the LUT-OUT pin when using the CCL.  They sent me a revised port multiplexing table and told me the datasheet was wrong. This new table has the XDIR in it, which is why I initially set the UPDI pin to GPIO so I could use it, but now I can't get it to change back. Microchip said they are working on a revised datasheet for the T412 to fix some errors.

 

 

This is the revised table they sent me. They did say this also may not be 100% accurate. But it explained the problem I was having. Unfortunately for the CCL when using start it uses the incorrect pins from the published datasheet (they are also going to fix that).

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

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Now, regarding that 12V activation to recover UPDI functionality, the documentation has not kept the same pace as the development.

 

First, for UPDI recovery the high voltage pulse threshold is around VCC*2, so a pulse between VCC*2 and 12V should work fine.

 

The procedure:

 - You can apply the high voltage pulse at any time.

 - When the pulse is applied the device will reset, and wait for a KEY.

    - If a KEY is not received within 65ms the device will continue operation as normal reset, and the pin will go back to it's non-UPDI configuration.

 - Enter the KEY as describe in the "Unified Program and Debug Interface (UPDI)" chapter in the datasheets. In most cases you would enter NVMPROG (0x4E564D50726F6720)

 - Then issue a reset for the KEY to take effect.

 - If you entered the NVMPROG KEY the device will now be in prog mode, and you can set the RSTPINCFG fuse back to UPDI mode.

Last Edited: Wed. May 22, 2019 - 07:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, in that case, since 65ms is about the limit of human perception of time, there is some chance that if you keep the programmer connected, and pulse the UPDI pin with 12V at the same time that you start avrdude, it will be able to connect within the 65ms window.

The 4.7k resistor should limit the current to the programmer's protection diode to (12-(VCC+diode drop))/4700 = less than 1.5mA assuming VCC = 5V. I suppose the protection diode can handle that for a moment. Maybe use an extra 1k resistor between the 12V power supply and the UPDI pin, to further limit current, since you just need about 10V.

 

That is, press S1, release at the same time you start avrdude. I wouldn't recommend this as it stresses the protection diode, but after a few tries it might be possible to connect.

Maybe put an extra Schottky protection diode to VCC would be a good idea?

 

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

Does the UPDI pin have a protection diode?  It was my understanding that the 12V tolerant /RESET pin on earlier AVR does not.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

No, I mean on the programmer's side, to protect it from the 12V.

 

like this:

Last Edited: Tue. Jan 8, 2019 - 07:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
No, I mean on the programmer's side, to protect it from the 12V.
Ah yes, I misunderstood the resistor you were referring to.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Hello El Tangas

 

Nice work.  I'm going to try to use your code as the basis of an ESP8266 program that to allows reprogramming of several connected ATTINY404s over WiFi, all running on 3.3v.  Ignoring the 12V need above, is there any actual reason for the 4.7k resistor between PD6 and UPDI ?  I'm designing the PCB first to accept these surface mount components directly so was wondering if I really need the resistor or not ?  I haven't seen any mention of it in the Microchip documents, but they are generally poor nowadays.

 

Many thanks in advance

 

                                             Vcc                     Vcc
                                              +-+                     +-+
                                               |                       |
 +----------+          +---------------------+ |                       | +--------------------+
 | PC       |          | Programmer          +-+                       +-+  Target            |
 | avrdude  |          |                     |      +----------+         |                    |
 |       TX +----------+ RX              PD6 +------+   4k7    +---------+ UPDI               |
 |          |          |                     |      +----------+         |                    |
 |       RX +----------+ TX                  |                           |                    |
 |          |          |                     |                           |                    |
 |          |          |                     |                           |                    |
 |          |          |                     +--+                     +--+                    |
 +----------+          +---------------------+  |                     |  +--------------------+
             JTAGICE MkII                      +-+     UPDI          +-+
             Protocol                          GND     Protocol      GND
Last Edited: Fri. Jan 11, 2019 - 10:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The resistor is not absolutely required, but since this is a bidirectional line, there is a small chance a short might develop if things go wrong.

I wouldn't omit the resistor. I adapted the design from pyupdi which was written by Atmel people and they use a resistor, so...

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

Ah ok - that makes sense.  Thanks very much

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

je_ruud wrote:

Now, regarding that 12V activation to recover UPDI functionality, the documentation has not kept the same pace as the development.

 

First, for UPDI recovery the high voltage pulse threshold is around VCC*2, so a pulse between VCC*2 and 12V should work fine.

 

The procedure:

 - You can apply the high voltage pulse at any time.

 - When the pulse is applied the device will reset, and wait for a KEY.

    - If a KEY is not received within 65ms the device will continue operation as normal, and the pin will go back to it's non-UPDI configuration.

 - Enter the KEY as describe in the "Unified Program and Debug Interface (UPDI)" chapter in the datasheets. In most cases you would enter NVMPROG (0x4E564D50726F6720)

 - Then issue a reset for the KEY to take effect.

 - If you entered the NVMPROG KEY the device will now be in prog mode, and you can set the RSTPINCFG fuse back to UPDI mode.

 

Back in September, I know for sure I was able to reprogram chips multiple times with the UPDI turned off, and I was doing it manually (no way it was timed within 65mS), touching a 12v supply lead to the programming pin.

 

Now I am not able to find any manual sequence that will allow me to reprogram the "bricked" chips -- which agrees with what  je_ruud says.

 

But what was allowing it to work manually before? I wish I had written down what I was doing more clearly :-(

 

For now, I have resigned myself that the 8-pin package ATtiny412 only has 5 pins that are usable, and left the UPDI as a dedicated pin. This invalidates the ATtiny412  for all but one of my intended uses.

 

Going with a (smaller, faster, more pins, reasonably usable and cheap SWD, and about the same price through my distribution) MKL03Z8VFG4 for the other projects :-(

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

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

Last Edited: Sat. Feb 2, 2019 - 08:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

baxsie wrote:
MKL03Z8VFG4
baxsie wrote:
Going with a (smaller, faster, more pins, reasonably usable and cheap SWD, and about the same price through my distribution) MKL03Z8VFG4 for the other projects :-(

 

That seems to be over a UK£1.   Surely the ATTINY412 is about one third the cost ?

 

But yes the whole programming the UPDI devices is a poorly documented mess !!   I'm using the 14 pin ATTINY404 which is cheapest at RS but leaving the UPDI pin unused for anything else.

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

Hi everyone, I'm playing with an ATtiny402. I'm able to write, compile and upload code to it through Atmel Studio and the jtag2updi running on an Arduino Nano. Having successfully connected the Nano to Atmel Studio for uploading purposes, does anyone have any ideas about how to get it recognised as a debugger? As the D in UPDI is for debugger and the JTAG part that Atmel Studio should be talking to can carry a debugging conversation between PC and uC, what would need to be done to get the Nano recognised as a debugger?

 

BTW, when I go to Tools\Device Programming in AS7, The Tool dropdown menu shows me a choice of Simulator or STK500 on my Nano's COM port. I know @ElTangas wrote this as an STK500 system (although I'd appreciate someone telling me how it identifies itself to AS7 as such) but can we do something that makes AS7 treat it as a debugger too? 

 

Thanks

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

smerrett79 wrote:
... but can we do something that makes AS7 treat it as a debugger too?
A very significant effort as the the debugger protocol is proprietary.

Edit : EDBG protocol is open and at Embedded Debugger-Based Tools Protocols User's Guide

 

 

 

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

Last Edited: Thu. May 16, 2019 - 01:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


smerrett79 wrote:
BTW, when I go to Tools\Device Programming in AS7, The Tool dropdown menu shows me a choice of Simulator or STK500 on my Nano's COM port. I know @ElTangas wrote this as an STK500 system (although I'd appreciate someone telling me how it identifies itself to AS7 as such) but can we do something that makes AS7 treat it as a debugger too? 

 

Actually, jtag2updi doesn't use the stk500 protocol, so you can't connect it to AS7 as an STK500. It uses a related, but different protocol called JTAGICE MkII.

The reason is that stk500 is quite old and doesn't support anything remotely similar to UPDI, while JTAGICE MkII supports PDI (xmega) which is close enough so that a little tweaking of the chip definitions inside the avrdude.conf file is enough to make it work with avrdude.

 

Now, why didn't I use something like stk600 or EDBG? The problem is that these use a USB interface instead of a COM port, and I have no experience with USB programming...

 

The problem of implementing a debugger is that the D in UPDI is (almost) undocumented. I have a bit on information, but certainly not enough to do something like that. At most, the programming interface could allow limited "debug" activities like r/w to SRAM and I/O registers, since it can access the whole memory space, not just flash and EEPROM.

 

 

edit: Basically, the programming/debugging tool is a bridge that translates the host/tool protocol to the tool/target protocol (in both directions).

Although the host/tool protocols are fully documented, the tool/target protocols are documented only in what regards programming; the debug part is proprietary. This makes it very difficult to make "homebrew" debugger tools.

 

Last Edited: Thu. May 16, 2019 - 09:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@gchapman thanks

 

@ElTangas thanks for all the work you did on jtag2updi and continuing to support those of us that want to know more. That diagram is very helpful. I did note your deliberate and efficient use of a COM based protocol when I first tried jtag2updi out - I would have done the same, were I to have your skills. I understand now that implementing the D in UPDI is a challenge.

 

You mention that we can read/write to memory so even reading a register value (which is the prime reason I would like a debugger) while the IC is running would be an amazing capability for me. Have I got any chance of this working with the current jtag2updi setup by using an avrdude command to read a memory address while the chip is running? I'm specifically thinking about the ADC conversion result in the ATtiny402 and perhaps a variable that I have set (although not sure quite how to give my variable a memory address that I know and will not change - you can smell the noob from there I imagine!).

 

  

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

Why dont you invest a little bit and buy Atmel ICE ? it supports the 0 series. it has full programming/debugging capability.

 

in the AS7, you can put the ADC_result value in the watch window if thats what you mean, there is also the I/O window so you can check all the registers value.

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

Moe123 wrote:

Why dont you invest a little bit and buy Atmel ICE ? it supports the 0 series. it has full programming/debugging capability.

I absolutely will. I'm also trying to make these chips more accessible for others who don't want to splurge on the ICE or similar if they're just dipping their toes in the water, for example if they want to take advantage of the 0 and 1 series ATtinys but have only used Arduinos before. With AS7, jtag2updi and beginner-friendly instructions, I think it's possible to equip someone to try these chips out and decide if they want to go further (perhaps investing in an ICE when they start to value the convenience and features).

Last Edited: Fri. May 17, 2019 - 09:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moe123 wrote:
in the AS7, you can put the ADC_result value in the watch window if thats what you mean, there is also the I/O window so you can check all the registers value.

This is the effect I'd be trying to achieve in a less polished way with the jtag2updi/avrdude

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

El Tangas wrote:
maybe not everyone wants to invest in a Atmel-ICE

In this case:

- go to farnell.com

- search for ATTINY416-XNANO

- here you have integrated UPDI programmer and DEBUGGER for every chip with UPDI for only 7,85 EUR

 

Alternatively you can buy ATmega4809 Curiosity board. It has power supply with regulated voltage (setting in Atmel Studio). Cost of the board is 9,50 EUR.

 

No need for any avrdude anymore, no usbasp, no need to waste time on thinking how to do something that is already done and cheap

extronic.pl

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

extronic wrote:

El Tangas wrote:
maybe not everyone wants to invest in a Atmel-ICE

In this case:

- go to farnell.com

- search for ATTINY416-XNANO

- here you have integrated UPDI programmer and DEBUGGER for every chip with UPDI for only 7,85 EUR

 

Alternatively you can buy ATmega4809 Curiosity board. It has power supply with regulated voltage (setting in Atmel Studio). Cost of the board is 9,50 EUR.

 

No need for any avrdude anymore, no usbasp, no need to waste time on thinking how to do something that is already done and cheap

 

 

Although I almost agree with you. but i think his point is that he wants to develop something out of curiousity...maybe he thinks he can sell it for cheaper price, while me and you thinks that this is completly a waste of time, well, for him it looks different. In everycase I dont even see the point of the whole project that he is doing. but I wish him good luck, its nice to see new ideas always...

 

Regards,

Moe

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

extronic wrote:

 

Alternatively you can buy ATmega4809 Curiosity board. It has power supply with regulated voltage (setting in Atmel Studio). Cost of the board is 9,50 EUR.

 

No need for any avrdude anymore, no usbasp, no need to waste time on thinking how to do something that is already done and cheap

 

Well, those things were not around when I started the project. I even have a couple of SNAPs and ATmega4809 Curiosity Nano boards, I would never buy the Atmel-ICE which IMO is grossly overpriced. 

 

Moe123 wrote:
Although I almost agree with you. but i think his point is that he wants to develop something out of curiousity...maybe he thinks he can sell it for cheaper price, while me and you thinks that this is completly a waste of time, well, for him it looks different. In everycase I dont even see the point of the whole project that he is doing. but I wish him good luck, its nice to see new ideas always...

 

I agree with you, there is no point to the project _now_. But on late 2017, when I started it, the only way to program UPDI chips was with Atmel ICE.

You will notice that I rarely recommend people asking about "how do I program my UPDI chip?" to use my software, unless they really don't want to spend _any_ money and already have the needed materials (i.e. a Mega328 based Arduino).

 

On the other hand, my time is never "wasted", I'm semi-retired so I have plenty of free time and I mostly do only what I want wink this project was also a way for me to learn/experimenting with C++.

 

If I wanted to make an hardware product, it would need to be able to do high voltage (12V) UPDI programming, to offer an advantage over the cheap Microchip programmers (e.g. for debricking UPDI chips where the programming pin had be accidentally disabled).

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

Xtronic, Moe123 and ElTangas all make good points. I think that many of the reasons I have got into a new topic is because someone has made a route into it using the things I am already familiar.

I'm certainly thankful that jtag2updi existed to get me interested and thanks for the reminder about the ATtiny xplained boards as a updi programmer. Just ordered one today.

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

In my opinion the Curiosity Nano has a superior debugger to the old Xplained Nano, although at a slightly higher cost... 

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

Hello.

I'm trying to setup fuses to an mega4809.

I want to setup BOOTEND and APPEND.

According to a previous post I placed a macro in my main.c file

 

FUSES = {
    .WDTCFG     = WINDOW_OFF_gc | PERIOD_OFF_gc,
    .BODCFG     = 0x00,
    .OSCCFG     = FREQSEL_20MHZ_gc,
    //  .TCD0CFG    =
    //  .SYSCFG0    =
    //  .SYSCFG1    =
    .APPEND     = 0xBF,
    .BOOTEND    = 0x20,
};

 

Using avr-objcopy I extracted a binary.

 

avr-objcopy -j .fuse my-app.elf -O binary fuses.bin

 

and I'm trying to flash the bin into the chip.

I tried:

 

avrdude -c jtag2updi -P com5 -p m4809 -Ufuses:w:fuses.bin
avrdude -c jtag2updi -P com5 -p m4809 -U fuses:w:fuses.bin
avrdude -c jtag2updi -P com5 -p m4809 -U fuse:w:fuses.bin

But nothing's working.

 

I get.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.22s

avrdude: Device signature = 0x1e9651 (probably m4809)
avrdude: NOTE: Programmer supports page erase for Xmega devices.
         Each page will be erased before programming it, but no chip erase is performed.
         To disable page erases, specify the -D option; for a chip-erase, use the -e option.
avrdude: reading input file "fuses.bin"
avrdude: can't determine file format for fuses.bin, specify explicitly
avrdude: read from file 'fuses.bin' failed

avrdude done.  Thank you.

 

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

Be careful! Fuses that are not explicitly defined may be set to zero, resulting in a bricked MCU that would need 12V programming to ressurect.

 

So don't comment out:

    //  .TCD0CFG    =
    //  .SYSCFG0    =
    //  .SYSCFG1    =

Set every fuse to the value you want, even if it's the default value!

Read this thread carefully: https://www.avrfreaks.net/forum/...

 

Now that the warning is given, the problem you have is that you need to specify the file format explicitly, because ".bin" files really have no format so avrdude can't auto-detect it:

 

avrdude -c jtag2updi -P com5 -p m4809 -U fuse:w:fuses.bin:r

Where ":r" means raw binary.

 

edit: Ah, wait, now I noticed that you are using a mega4809, which has a dedicated UPDI pin, so the chance of bricking it is low.

Last Edited: Sat. Jun 8, 2019 - 10:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, I'm strugling with this sentence in the datasheet of ATtiny404: "Enabling of the 1-wire interface, by disabling the Reset functionality, is either done by 12V programming or by fusing the RESET pin to UPDI by setting the RESET Pin Configuration (RSTPINCFG) bits in FUSE.SYSCFG0."

 

1.- Does it mean that I need another programmer to set that pin configuration register before using this UPDI programmer for Arduino that El Tangas has shared with us?

 

2.- Do I need 12v programming?

 

3.- Or, can I just program a brand new ATtiny404 with the tool that shared El Tangas?

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

A brand new device has UPDI enabled by default (fused), so you can program with any "low voltage" tool. 

If you do happen to change the UPDI pin into GPIO or /reset by changing the RSTPINCFG bits in the SYSCFG0 fuse, then you will need a 12V-capable programmer to get it back into UPDI mode again to be able to program it.

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

mraardvark wrote:
If you do happen to change the UPDI pin into GPIO or /reset by changing the RSTPINCFG bits in the SYSCFG0 fuse, then you will need a 12V-capable programmer to get it back into UPDI mode again to be able to program it.

 

I dont know if this is right. I happen to use the UPDI pin as a GPIO in a tiny412 (Custom board), I didnt need any 12v to get it back to UPDI.

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

Moe123 wrote:

mraardvark wrote:
If you do happen to change the UPDI pin into GPIO or /reset by changing the RSTPINCFG bits in the SYSCFG0 fuse, then you will need a 12V-capable programmer to get it back into UPDI mode again to be able to program it.

 

I dont know if this is right. I happen to use the UPDI pin as a GPIO in a tiny412 (Custom board), I didnt need any 12v to get it back to UPDI.

 

How did you do this exactly?

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

Well, I just configure it as a GPIO, i dont remember if it was an output or input. Using ATMEL-ICE i could use the same pin as UPDI and GPIO...its an old project, I will check if it was an o/p or i/p.

however, what i do remember clearly is that I also didnt need to change the FUSE settings for the UPDI PIN...give it a try

Regards,
Moe

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

okay, so here is the deal. If you want yo use the UPDI pin as a gpio and at the same time as a UPDI without getting into 12v issue, then you can use it in one case...you have to use it as an input pin. otherwise you cant.

only as an input can use the UPDI pin. if you use it as an output then you will get yourself into 12v programming.

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

Interesting. There are two questions remaining:

 

1. What is the chance that signals on the GPIO input may trigger UPDI programming and possibly interfere with program flow?

2. Did you try this with interrupts or only with slowly changing static input signals?

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

Moe123 wrote:

you have to use it as an input pin. otherwise you cant.

only as an input can use the UPDI pin. if you use it as an output then you will get yourself into 12v programming.

In either case, what ever is attached to the UPDI pin must be 12v tolerant or it's all for naught!

 

Jim

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

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

ki0bk wrote:

Moe123 wrote:

you have to use it as an input pin. otherwise you cant.

only as an input can use the UPDI pin. if you use it as an output then you will get yourself into 12v programming.

In either case, what ever is attached to the UPDI pin must be 12v tolerant or it's all for naught!

 

Jim


Jim, the question is whether you can use the pin as UPDI and as GPIO at the same time.

Great, now read the thread again.

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

drei wrote:

Interesting. There are two questions remaining:

 

1. What is the chance that signals on the GPIO input may trigger UPDI programming and possibly interfere with program flow?

2. Did you try this with interrupts or only with slowly changing static input signals?

For 1, I dont have answer, this you have to check it with an osci...in my case i never faced such a problem like this.

For 2: interrupts

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

Moe123 wrote:
I also didnt need to change the FUSE settings for the UPDI PIN...give it a try

 

So the pin is in UPDI mode, but you can still read the input? But in that case, certain input sequences will put the MCU in UPDI mode. You need to be sure such sequences will never happen, right?

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

Its like this, you cant really read the input, BUT you can flash your program again without the need for 12V. this means, the pin may work "fine" for basic functions...but you cant read whats going on...e.g. if you use it for ADC it will not be possible to read it

Last Edited: Mon. Aug 12, 2019 - 08:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have tested using the UPDI pin as I/O while keeping it configured as UPDI; you are right, it can be used as digital input for the most part. It's possible to read its logic value, and it can even trigger interrupts and events.

That is, the pin is under control of the UPDI unit, but the CPU unit can monitor and react to what is going on.

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

After several attempts this is my solution that seems to work reliably (tested with ATtiny814):

 

 

It turned out that the UPDI pin (when in its original fuse state) has an internal pullup resistor, approx. 20 to 30 kOhm. This pullup is not disabled even if the GPIO pullup is disabled. Therefore the best solution seems to be an open collector or open drain driver with appropriate decoupling. GPIO initialization in my case is as follows, directly taken from Atmel Start:

 

    OVERC_set_dir(PORT_DIR_IN);            // Set pin direction to input
    OVERC_set_pull_mode(PORT_PULL_OFF);

 

Here the input is used as an overcurrent detect for a CCL logic block.

 

Q1 decouples the rest of the circuit from the UPDI functionality. The jumper is normally not necessary, it can be left closed, UPDI programming works anyway provided Q1 is inactive during programming.

 

 

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

And using the UPDI pin as input also has the advantage that it is high voltage tolerant, so probably you can connect it to 5V logic even if the MCU is running at 3.3V (untested).

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

I would not try that. The voltage level could be near the 12V trigger point so it could inadvertently start the UPDI programming process. On the contrary I have chosen a solution that prevents input voltages exceeding Vcc.

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

drei wrote:
I would not try that. The voltage level could be near the 12V trigger point so it could inadvertently start the UPDI programming process.

 

Yeah, but where exactly is that trigger level? I think I read somewhere that it's about 2x VDD, but does anyone have some actual data?

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

El Tangas wrote:

Yeah, but where exactly is that trigger level?

 

Good question. That's why i would avoid it.

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

Besides, does the 12V UPDI enable actually do anything if UPDI is already enabled by fuse?

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

El Tangas wrote:

Besides, does the 12V UPDI enable actually do anything if UPDI is already enabled by fuse?


The high-voltage pulse won't do anything, but a falling edge on the UPD pin will wake the PDI-oscillator, which consumes some power. After a short period on inactivity it will go back to sleep again.

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

Has anyone figured out whether there is a well-defined serial sequence that you could send to the UPDI pin (in normal LV UPDI mode) that would cause a chip reset.

Something "send only" that could be output to the pin with a normal Serial connection, without needing the bi-directional hardware or support for more of the UPDI protocol?

Something like BREAK, <pause 10us-13.5ms>, SYNC, 'STCS RSTREQ, 59', BREAK, perhaps?

 

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

The sequence I use in jtag2updi is:

1) Double BREAK

2) Configure the UPDI - not needed here, can be skipped

3) Request RESET - SYNCH, STCS ASI_RESET_REQ, 0x59

(you don't need to wait here)

4) Release RESET - SYNCH, STCS ASI_RESET_REQ, (any 8 bit value other than 0x59, I use 0x00)

5) Wait a sensible amount of time for RESET completion.

 

In jtag2updi, point 5) is not a timed wait, I read ASI_SYS_STATUS and wait until the CPU is running, but since you don't want to do reads, a timed wait will do (100ms or so, I guess?).

 

Note: After a RESET, one of bits 1-3 of ASI_SYS_STATUS  will be set. You want bit 1 to be set (normal reset), not 2 or 3, these indicate special operating modes that will never happen unless a programmer is involved.

For some unfathomable reason, bit 1 is not documented in recent datasheets, but here it is: https://www.avrfreaks.net/commen...

 

6) You are also supposed to turn off the UPDI afterwards to save power, writing the relevant bit in CTRLB.

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

Thanks.  Does sending a BREAK without a sync afterward turn off the UPDI?
 

The datasheet says:

 

During the enable sequence the UPDI can disable itself in case of a faulty enable sequence. There are two cases which will cause an automatic disable.

  • A SYNCH character is not sent within 13.5ms after the initial enable pulse described in 32.3.2.1 UPDI Enable with Fuse Override of RESET pin.

But elsewhere it just says that the BREAK sets UPDI to its "default state."

 

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

This, I don't know. Maybe someone from Microchip can clarify?

 

In fact, how to know if the UPDI is enabled or not? By measuring power consumption? Probably not very reliable.

 

The only method I know is to observe with a scope how the UPDI pin reacts to a BREAK:

BREAK signal----4.7K--+--UPDI
                      |
                      |
                      observe with scope for ~15us

You will see a different response whether the UPDI was already enabled or not as described in this post (last 2 pics): https://www.avrfreaks.net/forum/...

Last Edited: Wed. Sep 4, 2019 - 09:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


UPDI can enable by this  sequence

 

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

UPDIprogrammer with Atmega32U4?

 

I just wondered if somebody compiled for the Atmega32U4?

I have some 'pro micro' boards here, but none with 328P - and a tiny202 I'd like to program.. or play around with.

 

Trying to compile gives you lots of errors when changing to 'Leonardo', mainly from io.h. Reason seams to be the missing defines for the USB2serial as that's not needed.

When I bought the pro micro not having to bother about the serial speed seemed fine for me - just until trying to UDPI up and running now after I got this tiny202.

 

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

My knowledge of USB is approximately zero, that's why jtag2updi relies on an external USB/Serial adapter doing all the USB work. So I didn't try to make it work with the Mega32U4, I'm afraid it's beyond my skills.

However, the Arduino developers made a derived version for the Nano Every that includes the USB stuff (called MuxTO), although not for the Mega32U4 but for the SAMD21 instead. But maybe it can be adapted?

Here is the link to their source code: https://github.com/arduino/Ardui...

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

not for the Mega32U4 but for the SAMD21 instead.

SAMD11, actually.  It actually uses the Arduino infrastructure/libraries for a lot of it (Serialx.read() instead of raw USB IO, for example), so I'd think that a port to 32u4 (aka Arduino Leonardo or Arduino Micro) would be relatively easy.

(It's impressive how much (from jtag2updi) was changed and how much could be left alone.  It gives me warm fuzzy feelings about the modularity and quality of both the original code, and the port...)

 

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

westfw wrote:

not for the Mega32U4 but for the SAMD21 instead.

SAMD11, actually.  It actually uses the Arduino infrastructure/libraries for a lot of it (Serialx.read() instead of raw USB IO, for example), so I'd think that a port to 32u4 (aka Arduino Leonardo or Arduino Micro) would be relatively easy.

(It's impressive how much (from jtag2updi) was changed and how much could be left alone.  It gives me warm fuzzy feelings about the modularity and quality of both the original code, and the port...)

 

 

This is a strange one, and I posted recently on the arduino.cc forum about it. The MuxTO code uses a 3rd party core for the SAMD11 which hasn't been updated in a couple of years (https://github.com/mattairtech/A...). I've used this core on other projects (for SAMD11, and SAMC21 because of CAN bus) and it works well. It is itself a fork of the official Arduino SAMD core.

 

But I'm a little wary of having a dependency on some code that seems, at least, a little unloved. Of course, it could be forked and brought up to date, but that's beyond my skill level.

 

That said, it compiles and works, so maybe I shouldn't worry too much.

Last Edited: Thu. Dec 26, 2019 - 05:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for that tip. I'll give it a look - if it seems to complicated I'll order some 328P and wait some days to get those..

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

Back again - I took a look at the code from the megaavr project including the SAMD11.

All changes have to be done to JICE_io.cpp and JICE_io.h - and only a few lines.

 

So I included in JICE_io.h:

#warning "modify this to match your USB serial port name"
#define SERIALCOM Serial

and in JICE_io.cpp lines like (in io::put):

#elif __AVR_ATmega32U4__
  SERIALCOM.write(c); //test 32U4
  return c;           //test 32U4

 

When not using SERIALCOM it compiles fine, but with SERIALCOM I get:

JICE_io.h:16:19: error: 'Serial' was not declared in this scope

 #define SERIALCOM Serial

When writing data to USB in my other sketches using Leonardo/proMicro I use Serial for writing to USB (and Serial1 for the UART). So I'm a bit confused why I'm getting that error here.

 

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

Where is "Serial" defined? Maybe you need to include that header explicitly? Or is it supposed to come from "Arduino.h"?

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

I had never thought of that before, actually, as 'Serial' and 'Serial1' work fine with 'normal' sketches.

 

Therefor I took a look in Arduino.h now:

It includes 'HardwareSerial' where the normal 'Serial' are defined:

#ifdef __cplusplus
#include "WCharacter.h"
#include "WString.h"
#include "HardwareSerial.h"
#include "USBAPI.h"
#if defined(HAVE_HWSERIAL0) && defined(HAVE_CDCSERIAL)
#error "Targets with both UART0 and CDC serial not supported"
#endif

 

As your files are cpp ones that should work, or?

 

For the 32U4 it's Serial1:

#if defined(UBRR1H)
  extern HardwareSerial Serial1;

the ones for Serial (#if defined(UBRRH) || defined(UBRR0H)) are not there, as it's a USB one.

 

But in USBAPI.h there actually is the part for Serial.

And USBAPI.h is also included in Arduino.h

 

 

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

I tried to compile on the Arduino IDE for the Leonardo and the Micro, that contain the Mega32U4, and it doesn't complain about Serial; "JICE_io.cpp.o" was built. There are other errors, hinting that some work will be needed to get it going.

 

edit: Maybe you can convince the Arduino devs to do it? Perhaps posting an issue on the GitHub repository?

Last Edited: Fri. Dec 27, 2019 - 05:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Strange. I'm using Arduino 1.8.10 and have 'Arduino Leonardo' selected (on a Win10 machine).

I first compiled having added #elif __AVR_ATmega32U4__ and 'return 0' where return was needed, and that compiled without any errors/warnings.

Would it be a good idea to add a branch 'Arduino_32U4' or alike?

And I just saw that JICE_io.h is 'incorporated' in sys.h.. I added the #define SERIALCOM Serial even there. Same error.

When I change Serial to Serial1 I get the same error when compiling.

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

In the version of MuxTo I have, JICE_io.cpp starts with:

 

// Includes
#include <Arduino.h>
#include "JICE_io.h"
#include "sys.h"

 

instead of

 

// Includes
#include <avr/io.h>
#include "JICE_io.h"
#include "sys.h"

 

You need to include Arduino.h somewhere.

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

Well, that helped. Now everything compiles without error. Thanks. So I'll continue with the next steps and have a look how far I get.

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

Now I installed SpenceKonde's megatinycore, added the 10uF cap to avoid reset and uploaded. Result: the Leonardo is not visible any longer. After disconnecting/reconnecting it appears again for about a second as 'LeonardoBootloader' then disappears again. Then the jtag2updi should be running I guess. But no port is visible any longer - neither in the IDE nor in windows device manager.

 

I was able to do a 'reset' to the Leonardo flashing another sketch while bootloader was active, but didn't have the possibility to flash the attiny.

Attachment(s): 

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

As I said, I'm not good with USB devices. You need to get that serial port showing and I can't help there. Then send this sequence with a terminal program capable of sending hex values:

0x1b 0x00 0x00 0x01 0x00 0x00 0x00 0x0e 0x01 0xf3 0x97

 

 

If the serial link is working, the programmer will reply with:

0x1B 0x00 0x00 0x1D 0x00 0x00 0x00 0x0E 0x86 0x01 0x01 0x00 0x06 0x01 0x01 0x00 0x06 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x4A 0x54 0x41 0x47 0x49 0x43 0x45 0x20 0x6D 0x6B 0x49 0x49 0x00 0x3C 0x7F   

 

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

Is the current state of your code uploaded to github or something so that it'd be easy to look at?

 

the lack of USB presence probably indicates that the Arduino USB initialization code isn't happening correctly....

 

 

I first compiled having added #elif __AVR_ATmega32U4__

I'm sort-of thinking that you DON'T want to do that in a lot of places.   You're probably getting 32u4 "bare metal" code where what you really want is "code that uses the Arduino abstraction layer" ...

 

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

Guess you're right with the serial port. For doing that I'll have to dig in a bit how an Arduino actually works. I didn't even realize before that the 32U4 showed up with two different serial ports - one for bootloader and another one when sketch is running before. So the port get's initialized when the Sketch is starting (at 32U4). I don't know if it's the same having a 328P (or the 4809 with SAMD11) as they're both using an extra chip for USB communication. I'll have a look how the initialization of USB is done at 32U4. Maybe I'll buy a 328P in the meantime. ;-)

 

I didn't expect you to solve the problems with porting to a new Arduino for me - but I thought as it's a forum to get a few hints on where I'm doing wrong. The hints I got from you where really helpful pointing where to look. And it commands me admiration of all your knowledge and effort you're putting into this project. Thanks.

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

Hi westw, I thought creating a branch '32U4' or alike in git would be nice, but I can't create one. So I raised an issue on jtag2updi, hoping the one with the rights to do that will react. Don't know it that's the right way to do.

 

I'll have a look how the USB init is done. As I needed to add 'include Arduino.h' which you don't have to do using 'normal' sketches indicates that some parts are not included here. So some part learning left for me to do. And yes, I'd rather go for abstraction layer than 'bare metal' code.

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

linuxisgood wrote:
I raised an issue on jtag2updi, hoping the one with the rights to do that will react. Don't know it that's the right way to do.

 

Normally, when people want to add features to jtag2updi or create some derived work like MuxTO, they start by creating a fork.

So, I recommend that you create one, this way you can work calmly on the 32U4 port independently from me. I will help, of course, in what I can. When the port is operational, you can submit a pull request and I will consider merging it into the main branch.

 

Currently I'm working on porting jtag2updi to the AVR-0/1 architecture so the timing is not the best. I like to focus on one thing at a time.

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

Hi again, created a fork '32U4_support' now. I added some lines to jtag2updi.cpp for the USB interface to come up.

The reply for the hex-string sent is as expected, but in the Arduino IDE the board info is till 'Leonardo' - is it expected that way?

The COM-port used by USB is busy while up, but RealTerm shows reply as expected.I

 

I tried to upload an empty sketch to the t202. It tries to upload quite a while, ending up with: 'an error occured uploading...'

Would it be useful to watch with an oscilloscope on pin D6?

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

I think there are conflicts because the Arduino init functions will surely enable interrupts. This will mess up the timing of the bitbang UART present in updi_io_soft.cpp so you will need to disable interrupts inside the functions present in that file, then reenable on exit.

This may or may not work.

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

I took a look in Arduino.h. The init() seems to be empty as far as I could see. But the USB uses interrupts ISR..

 

Then I put my scope on Pin D6 - couldn't see anything there. So it's not just timing. I'll have to dig into the code a bit deeper I guess - and into differences between 328P and 32U4.

  • 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