AVR Freaks

mEDBG_UPDI_firmware_1.09.zip

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

Posted by MCUdude: Tue. Mar 19, 2019 - 11:41 PM

Hi!

I have a few Xplained boards with onboard mEDBG chips (ATmega32u4). I recently found out that these mEDBG chips are completely open in terms of the lock bits, and dumping the flash and EEPROM was as easy as connecting an Atmel ICE and dumping everything through Atmel Studio. The reason why I'm doing this is that I want a standalone programmer for programming UPDI compatible devices.

I started comparing the simplest mEDBG based board I have, the ATtiny817 Xplained mini. I dumped the flash and EEPROM content and loaded it into my Olimex 32u4 board. After setting the correct fuses the Olimex board did show up as an available programmer in Atmel Studio. So far so good!

To test the Olimex programmer I just "made" I disconnected the onboard mEDBG chip on the Xplained 817 board by removing a 0R resistor, and I connected pin PE6 on the Olimex board to the target (ATtiny817). Using Atmel Studio I was able to read the device signature, read and write to flash and EEPROM and set fuses. However, the target voltage seems to be stuck at 3.3V even though the target is powered at 5V. The onboard mEDBG did report 5V before I removed the 0R resistor.

First question: How does the mEDBG chip reads the target voltage? And why does my standalone programmer reads 3.3V even if I tie every free pin to 5V?

It's time to test the standalone board with Avrdude. As I start I'm just trying to read the device signature of the Attiny817 with Avrdude using the Olimex board:

avrdude -C/path/to/avrdude.conf -v -pattiny817 -cxplainedmini_updi -Pusb

Avrdude detects the programmer and returns 3.3V as the target voltage (even though is 5V), but I always get this exact error when I run the command for the first time:

avrdude: Short read, read only 0 out of 64 bytes
avrdude: jtag3_edbg_recv(): Unexpected response 0x12
avrdude: retrying with external reset applied
avrdude: jtag3_edbg_send(): Unexpected response 0x81, 0x11
avrdude: jtag3_edbg_recv(): Unexpected response 0x80
avrdude: retrying with external reset applied
avrdude: JTAGEN fuse disabled?
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: jtag3_edbg_send(): Unexpected response 0x81, 0x11
avrdude: jtag3_edbg_recv(): Unexpected response 0x80
avrdude: jtag3_edbg_send(): Unexpected response 0x81, 0x11
avrdude: jtag3_edbg_recv(): Unexpected response 0x80
avrdude: jtag3_edbg_signoff(): unexpected response 0x81, 0x11
avrdude: jtag3_edbg_signoff(): unexpected response 0x01, 0x00

avrdude done.  Thank you.

If I run the exact same command again Avrdude still detects the programmer, but I now get this error. I'll need to unplug the programmer and re-insert it in order to get the previous error.

avrdude: jtag3_edbg_recv(): Inconsistent fragment number; expect 1, got 0

avrdude done.  Thank you.

It seems like Avrdude struggles with the mEDBG chip. However, if I add the 0R resistor to the Xplained 817 board again and uses the onboard mEDBG chip (the one I dumped the firmware from) to communicate with the ATtiny817 it works like a charm! I really don't understand this.

How can my custom programmer work with Atmel Studio but not with Avrdude?

I've attached the dumped hex and eep file from my (working) Xplained 817 mEDBG chip for reference

Attachment(s):

Tags:

Tools, In-System Debuggers and Programmers

Last Edited: Tue. Mar 19, 2019 - 11:43 PM

El Tangas

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 2899 View posts

Posted by El Tangas: Wed. Mar 20, 2019 - 12:46 AM

MCUdude wrote:

First question: How does the mEDBG chip reads the target voltage? And why does my standalone programmer reads 3.3V even if I tie every free pin to 5V?

No idea. But I would take a look at the xplained mini schematic, see exactly where each of the I/O pins of the mEDBG are connected and replicate that on the Olimex board.

You only mention PE6, but there must be more connected pins.

edit: for example PE2 has an external pull-up, maybe it's needed for correct operation.

Last Edited: Wed. Mar 20, 2019 - 12:50 AM

Level: Hangaround

Joined: Mon. Nov 21, 2016

Posts: 106 View posts

Location: Trondheim, Norway

Posted by mraardvark: Wed. Mar 20, 2019 - 05:22 AM

If you can get hold of a Curiosity Nano I think it has a far better UPDI programmer than the old Xplained Mini...

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

Posted by MCUdude: Wed. Mar 20, 2019 - 05:58 AM

But I would take a look at the xplained mini schematic, see exactly where each of the I/O pins of the mEDBG are connected and replicate that on the Olimex board.

I've tried to look at the schematic and tried connecting each IO pin to either vcc or gnd, but it still reads 3.3V.

If you can get hold of a Curiosity Nano I think it has a far better UPDI programmer than the old Xplained Mini...

I do have a Curiosity Nano. I've not tried to use it as a standalone programmer though. Would you mind explaining why the nEDBG is superior to the mEDBG? The reason why I originally would like to use the ATmega32u4 is that then anyone with the need for a UPDI programmer could just buy a cheap Arduino Leonardo or pro micro and use it with very little (no?) extra hardware.

The Olimex board has an additional button connected to the HWB pin. I tried to keep this pressed (tied to ground) while applying power to the board, but don't enter DFU mode like when I short the BOOT jumper on the Xplained 817 board. The efuse if 0xf6, so the HBWE fuse is set. Does this mean the Olimex probably have a malfunctioning bootloader?

Level: Hangaround

Joined: Mon. Nov 21, 2016

Posts: 106 View posts

Location: Trondheim, Norway

Posted by mraardvark: Wed. Mar 20, 2019 - 07:16 AM

The mEDBG boards have UPDI connected to PE6, which is not a UART pin. The mega32U4 only have one UART, which is used for CDC - so UPDI is bit-banged. Slower, and perhaps more prone to error?

The nEDBG boards have a SAMD21 debugger, which is a more capable part with plenty of SERCOM modules for UPDI and CDC.

The mEDBG boards are single-voltage boards, meaning the debugger and device are running at the same voltage. When lowering the voltage on the system, the clock must be lowered as well.

The nEDBG boards have level shifters, since the SAMD21 is a 3V part. This complicates things in some respects, but makes it more versatile.

I do agree with your statement that the mega32U4 boards are easier to come by. But the SAMD21 is a step up in many respects.

You choose ;)

https://github.com/mraardvark/py...

Level: Hangaround

Joined: Mon. Nov 21, 2016

Posts: 106 View posts

Location: Trondheim, Norway

Posted by mraardvark: Wed. Mar 20, 2019 - 07:58 AM (Reply to #5)

Forgot to mention: pyupdi works on both mEDBG and nEDBG boards using the CDC and a resistor

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

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

Posted by MCUdude: Wed. Jul 31, 2019 - 09:10 PM

Sorry for bringing this old thread back to life again, but I believe I figured out the issue!

It suddenly started to work when I connected the AREF pin to Vcc instead of leaving it floating.

This means it's very simple to take a 32u4 based Arduino Micro (clone) and turn it into a UPDI programmer + USB to serial adapter!

DocJC

Level: 10k+ Postman

Joined: Tue. Dec 11, 2007

Posts: 12833 View posts

Location: Cleveland, OH

Posted by DocJC: Thu. Aug 1, 2019 - 11:00 PM

I connected the AREF pin to Vcc instead of leaving it floating.

I'll just mention for others that might come across this Thread that that is generally a BAD IDEA.

There are times when one might wish to connect Aref to Vcc, but usually one can leave it not connected, or just put a 0.1 uF by-pass cap from the pin to Ground, and select Vcc as the analog circuitry reference voltage by setting a bit or two within a register.

The issue is this:

If the Aref pin is hard wired to Vcc, and the software, either intentionally, or accidentally, sets, via the registers, the Aref voltage to another voltage level, then internally the two will fight to control the pin.

This can/will damage the analog circuitry, and perhaps the entire chip.

It is generally a bad idea to have a hardware design, (tie the Aref to Vcc, for example), with which the software can precipitate hardware destruction.

There are two, (or perhaps 3), sides to every coin.

And now you are at least aware of the flip side of this action.

joeymorin

Level: 10k+ Postman

Joined: Tue. Jul 17, 2012

Posts: 11487 View posts

Location: Location, Location

Posted by joeymorin: Fri. Aug 2, 2019 - 12:44 AM

DocJC wrote:

It is generally a bad idea to have a hardware design, (tie the Aref to Vcc, for example), with which the software can precipitate hardware destruction.

"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]

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

#10

Posted by MCUdude: Fri. Aug 2, 2019 - 06:07 AM

I'll just mention for others that might come across this Thread that that is generally a BAD IDEA.

I'm fully aware of this, but that's what I had to do in order to get the closed source mEDBG firmware to work on my own 32u4 based hardware.

Have a look at the ATtiny817 Xplained Mini schematics. AREF on the 32u4 is tied to Vcc. Don't blame me!

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

#11

Posted by MCUdude: Sun. Aug 4, 2019 - 01:13 PM

If anyone's interested to know what this turned into, everything is hosted here: https://github.com/MCUdude/microUPDI

Level: Raving Lunatic

Joined: Wed. Jun 19, 2002

Posts: 4296 View posts

Location: SF Bay area

#12

Posted by westfw: Mon. Sep 23, 2019 - 05:22 AM

Did you ever get avrdude working consistently with your ATtiny817 Xplained board using avrdude?

I seem to get "avrdude: jtag3_edbg_signoff(): unexpected response 0x03, 0x80" after the first power-cycle, and

"avrdude: jtag3_edbg_recv(): Inconsistent fragment number; expect 1, got 0" thereafter...

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

#13

Posted by MCUdude: Mon. Sep 23, 2019 - 06:30 AM

I've never had any issues with the 817 Xplained mini, but I've had similar errors on my 416 Xplained board. Try upgrading the mEDBG firmware. The latest version I've been able to retrieve is 1.13.

Level: Raving Lunatic

Joined: Wed. Jun 19, 2002

Posts: 4296 View posts

Location: SF Bay area

#14

Posted by westfw: Mon. Sep 23, 2019 - 10:35 AM

Try upgrading the mEDBG firmware. The latest version I've been able to retrieve is 1.13.

Hmm. I have 1.0d ...

I guess the only way to get newer firmware is a new AS7 install? It doesn't seem to be in any of the "extensions" areas that are easy to update :-(

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

#15

Posted by MCUdude: Mon. Sep 23, 2019 - 10:53 AM

I pulled 1.13 out from an Uno Wifi Rev2. It's hosted on my Github.

Last Edited: Mon. Sep 23, 2019 - 10:54 AM

Level: Hangaround

Joined: Thu. Feb 14, 2019

Posts: 355 View posts

Location: Los Angeles area

#16

Posted by MattRW: Mon. Sep 23, 2019 - 01:24 PM

Thanks for waking up this thread. I have arduino micro and have some 4809 PDIPs coming soon and was going to start such a project on breadboard.

Level: Raving Lunatic

Joined: Wed. Jun 19, 2002

Posts: 4296 View posts

Location: SF Bay area

#17

Posted by westfw: Mon. Sep 23, 2019 - 09:09 PM

Well, there doesn’t seem to be new firmware in the new as7, and the Atmel atfw.exe tool seems to want an xml file with md5 cksum, inside a zip...

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

#18

Posted by MCUdude: Mon. Sep 23, 2019 - 09:20 PM

I soldered a 10pin 1.27mm header to the Xplained 817 the so I could connect an Atmel Ice to the mEDBG chip. I just loaded the hex and eep using the device programming window.

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

#19

Posted by MCUdude: Tue. Sep 24, 2019 - 06:54 AM

For those who are interested, I'm planning to design a 12V version of the microUPDI board. It will still be powered from USB but 12V is generated on the board by a diode/capacitor voltage multiplier. It everything works out in the end, it should be possible to connect a target where the UPDI pin is turned into RST or a GPIO. When a button is pushed a 12V pulse is injected (500-1000us) followed by pulling the UPDI line to the ground for about 50 milliseconds.

The 12V part of the UPDI interface isn't well documented so this will require some testing. Hopefully, the microcontroller will just sit there and wait for commands after the 12V pulse have been injected, without any timeout.

Level: Raving Lunatic

Joined: Wed. Jun 19, 2002

Posts: 4296 View posts

Location: SF Bay area

#20

Posted by westfw: Tue. Sep 24, 2019 - 09:46 AM

I've been wondering whether it might be cheaper/easier to just stick one of those A23 12V remote-control batteries on there, instead of messing with voltage multipliers.

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

#21

Posted by MCUdude: Tue. Sep 24, 2019 - 09:49 AM (Reply to #20)

The voltage divider is quite simple. It's the exact timing of the 12V pulse that requires some MOSFET logic. But by using SOT363's SOT23's and 0805's it shouldn't occupy too many square centimeters.

Level: Hangaround

Joined: Thu. Feb 14, 2019

Posts: 355 View posts

Location: Los Angeles area

#22

Posted by MattRW: Tue. Sep 24, 2019 - 01:09 PM

For myself and some others, I'm posting the 12 V source I found here

Note: Older AVR devices have a programming interface, known as "High-Voltage Programming" (both serial and parallel variants exist.) In general this interface requires 12V to be applied to the /RESET pin for the duration of the programming session. The UPDI interface is an entirely different interface. The UPDI pin is primarily a programming and debugging pin, which can be fused to have an alternative function (/RESET or GPIO). If the alternative function is selected then a 12V pulse is required on that pin in order to re-activate the UPDI functionality.

Level: Hangaround

Joined: Thu. Feb 14, 2019

Posts: 355 View posts

Location: Los Angeles area

#23

Posted by MattRW: Tue. Sep 24, 2019 - 01:18 PM

DocJC wrote:

I connected the AREF pin to Vcc instead of leaving it floating.

I'll just mention for others that might come across this Thread that that is generally a BAD IDEA.

There are times when one might wish to connect Aref to Vcc, but usually one can leave it not connected, or just put a 0.1 uF by-pass cap from the pin to Ground, and select Vcc as the analog circuitry reference voltage by setting a bit or two within a register.

...

Here is the Arduino micro schematic:

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

#24

Posted by MCUdude: Tue. Sep 24, 2019 - 01:45 PM (Reply to #23)

All I know is that I could not communicate with the target using Avrdude if I didn't connect the AREF pin to Vcc. The Xplained ATtiny817 board and the Arduino UNO Wifi Rev2 does exactly this, so I'm guessing it is safe if you load the mEDBG binary. Why is this such a big deal?

Level: Hangaround

Joined: Thu. Feb 14, 2019

Posts: 355 View posts

Location: Los Angeles area

#25

Posted by MattRW: Wed. Sep 25, 2019 - 12:46 AM

Some detail on the 12v pulse here

ki0bk

Level: Raving Lunatic

Joined: Mon. Sep 8, 2014

Posts: 6665 View posts

Location: Olathe KS

#26

Posted by ki0bk: Wed. Sep 25, 2019 - 01:46 AM (Reply to #24)

You can probably connect AREF to VCC through a 100k resistor, the ref does not need much current,
that should prevent any damage.
Jim

See: https://www.avrfreaks.net/comment/2616176#comment-2616176

Level: Hangaround

Joined: Mon. Nov 21, 2016

Posts: 106 View posts

Location: Trondheim, Norway

#27

Posted by mraardvark: Wed. Sep 25, 2019 - 08:14 AM

MCUdude wrote:

Hopefully, the microcontroller will just sit there and wait for commands after the 12V pulse have been injected, without any timeout.

Who-me

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2238 View posts

#28

Posted by Who-me: Thu. Sep 26, 2019 - 08:51 PM

MCUdude wrote:

The voltage divider is quite simple. It's the exact timing of the 12V pulse that requires some MOSFET logic. But by using SOT363's SOT23's and 0805's it shouldn't occupy too many square centimeters.

You could also consider the ST662 - a So8 charge pump to 12V regulated ? - fewer parts, and gives a more accurate 12V

Level: Hangaround

Joined: Mon. Nov 21, 2016

Posts: 106 View posts

Location: Trondheim, Norway

#29

Posted by mraardvark: Fri. Sep 27, 2019 - 02:17 PM (Reply to #28)

Who-me wrote:

You could also consider the ST662 - a So8 charge pump to 12V regulated ? - fewer parts, and gives a more accurate 12V

I don't think that accuracy is an issue. The requirement is 2*Vdd, which means even 3.6V could be enough when running at 1.8V...

Level: Rookie

Joined: Wed. Sep 27, 2017

Posts: 21 View posts

Location: Telemark

#30

Posted by MCUdude: Fri. Sep 27, 2019 - 06:17 PM

Well, generating 12V is not an issue. What is an issue is the 65ms timeout on newer tiny0/tiny1's after the 12V pulse has been injected to the UPDI line.

In order to make a 12V programmer where we can just push a button to enter programming mode, we need some kind of KEY injector (which the newer ATtinys require). We could use a small microcontroller (ATtiny202/402?) to drive the voltage multiplier, time the 12V pulse and inject the key before the 65 ms timeout occurs.

I'm absolutely no expert when it comes to UPDI, so I'm not capable of writing such a microcontroller firmware. However, if someone is, I'll be happy to design the rest of the hardware and make the design open-source.

If we can make such a firmware we would have a capable (mEDBG) programmer that can change ANY fuse, and access a disabled UPDI interface with a click of a button.

EDIT:
Similar discussion here: https://github.com/MCUdude/micro...

Last Edited: Fri. Sep 27, 2019 - 06:20 PM

Who-me

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2238 View posts

#31

Posted by Who-me: Sat. Sep 28, 2019 - 12:29 AM

MCUdude wrote:

Well, generating 12V is not an issue. What is an issue is the 65ms timeout on newer tiny0/tiny1's after the 12V pulse has been injected to the UPDI line.

I guess that fix is to prevent a stray spike locking out a MCU, into PGM mode.

MCUdude wrote:

In order to make a 12V programmer where we can just push a button to enter programming mode, we need some kind of KEY injector (which the newer ATtinys require). We could use a small microcontroller (ATtiny202/402?) to drive the voltage multiplier, time the 12V pulse and inject the key before the 65 ms timeout occurs.

What about using a serial handshake line to enable the 12V ? You can control handshakes to 1ms or better timing, so 65ms is a long time.

Or, you could use a simple set/reset latch that clears charge pump enable, on the first UART character ?

Level: Raving Lunatic

Joined: Wed. Jun 19, 2002

Posts: 4296 View posts

Location: SF Bay area

#32

Posted by westfw: Sat. Sep 28, 2019 - 04:34 AM

If you can program the micro, you could even have the Arduino DTR-drop or 1200bps feature trigger a 12V UPDI reset sequence instead of a traditional reset. MCUDude's issue is that he'd like the programmer to run "stock" mEDBG firmware.