uPDI Confusion

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

I'm confused. We have yet another programming and debugging interface to contend with on the form of uPDI. On the face of it a one-pin interface is a good idea. But I'm not sure if we can use it.

 

I'm interested in the new tinyAVR 1-Series devices. On the face of it they look to be something that Atmel traditionally lacked in that they are a family of devices with pin counts of 8, 14, 20 and 28 pins, and memory sizes running from 2k all the way up to 16k (with hints of 32k to come) with a consistent set of peripherals. Nice.

 

To program and debug them the only device that supports them is the Atmel-ICE. In the manual it does however say...

 

Quote:

Important: The Atmel-ICE does not support 12V on the UPDI line. In other words, if the UPDI pin has been configured as GPIO or RESET the Atmel-ICE will not be able to enable the UPDI interface.

 

...but in the device datasheet it says...

 

Quote:

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.

 

But how on earth do you set the fuse bit if you can't get into programming mode?

 

I'm hoping that the bit is set by default and that if you want to use the reset pin as /reset you have to enable that option but there's nothing in the datasheet to help answer that. The JTAG-ICE3 manual does say this...

 

Quote:

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.

 

...which implies that the default is that the pin is a programming/debug pin.

 

But who knows.

 

I may open a support ticket when I get back from holiday and see if anyone at HQ knows.

 

 

I am increasingly frustrated at how disjointed and out of step all the Atmel documentation and website is. It feels decidedly un-cared about.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

Found it.

 

At 'reset' the pin does come up in uPDI mode.

 

But if you are unlucky enough to change it to something else and then want to go back to debugging then you are out of luck as nothing will supply the 12v needed to undo the change.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

Just look at it like an improved debugWIRE.

 

The programming and debug comms work better and faster.  

You don't need to worry about DWEN

 

You always have to avoid RSTDISBL unless you want to commit hari-kari.

Personally,  I can live without using RST as a GPIO pin.   But many members have an overwhelming desire to shoot their feet.

 

Yes,  it is a nice idea to have a "single wire debug" that actually uses a single wire.   e.g. debugWIRE.

I am very happy with PDI on Xmega or SWD on ARM-Cortex but both use two wires.  

Single wire operation is always going to be slower.   debugWIRE with ATMEL-ICE is slow.  debugWIRE with mEDBG is painful.

uPDI with mEDBG is not bad.   I suspect that ATMEL-ICE might be a bit quicker.

 

David.

Last Edited: Fri. Aug 4, 2017 - 10:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

According to the "Development Tools" at the bottom of this page:

http://www.microchip.com/wwwproducts/en/ATtiny817

the Power Debugger and STK600 supports the ATtiny817 (and must therefore support UPDI). I believe both also supports 12 V :)

 

If anyone else wonders, the default value of the RSTPINCFG fuses can be found in "6.9.4.5 System Configuration 0" descriptions for SYSCFG0.

 

If you have changed the RSTPINCFG fuse to something other than UPDI, why not disconnect the Atmel-ICE, power cycle the AVR and whack the reset pin with one 12 V pulse from your prefered 12 V supplier, before reconnecting the Atmel-ICE and doing your UPDI stuff. The way I read chapter 33.3.2.2, it should work... The UPDI pins should remain UPDI until the next POR, so you should have plenty of time to reconnect the Atmel-ICE.

 

CPL

 

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

Threiran wrote:
I believe both also supports 12 V :)
STK600 does.

Power Debugger does generate 12V from USB VBUS but 12V stops within the level converters.

Power Debugger

Programming and Debugging

http://www.atmel.com/webdoc/GUID-EAD481FD-28E6-4CD5-87FB-5165E7687C12/index.html?GUID-15319D51-090D-4BC4-9361-0FC2A4A0983B

...

All signal channels can be operated in the range 1.62 to 5.5V, although the Power Debugger hardware itself can not drive out a higher voltage than 5.0V.

...

 

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

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

The Power Debugger does have 12 volt capability on the UPDI pin. I pointed out to an Atmel support person the paragraph that stated a ~5V limit on its pins and she replied that she would contact the relevant group about correcting the documentation. Dealing with the UPDI pin is a bit tricky; here's what I have learned.

 

1. UPDI devices (the ATtiny814 in my case) ship with the RESET pin set for UPDI operation. This allows debugging out of the chute. 

2. You change RESET pin functionality using the Tools->Device Programming screen, selecting Fuses, then scrolling down to the SYSCFG0.RSTPINCFG (Reset Pin Configuration) selection. It will normally show as "UPDI mode". If you want to disable UPDI, select GPIO or RESET. I don't want a RESET pin so I pick GPIO. After a warning message the "fuse" setting is reconfigured. IT DOES NOT TAKE IMMEDIATE EFFECT. The "fuse" value has changed, but fuses don't take effect until the next power cycle.  

3. To re-enable UPDI communication, go to Tools->Device Programming again, and note a checkbox called "Use 12V UPDI activation if available". Checking this box tells the Power Debugger to generate the 12V pulse on the RESET pin to re-enable UPDI and therefore debugging. It does this when you click the "Set" button, but note this: UPDI debugging is enabled, but the fuse setting is still GPIO. This means that at the next power cycle you're out of luck again for debugging. The solution is that once you have (temporarily) restored UPDI communication with the 12V pulse, you must also change the RSTPINCFG setting to UPDI. This makes the RESET pin UPDI, permanently. 

 

Why disable UPDI, anyway? Two obvious reasons are that you want an external hardware RESET signal, or you are so strapped for GPIO that you need just one more pin. A more subtle reason (mine) is that as long as the UPDI interface is enabled, a tiny amount of current is consumed by the UPDI logic which includes a low power oscillator. If you want the lowest possible power consumption in low power modes you must disable the UPDI which stops its oscillator. 

 

 

 

 

I took a course in speed reading and was able to read War and Peace in twenty minutes. It's about Russia. --Woody Allen

Last Edited: Tue. Aug 7, 2018 - 07:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aging_nerd wrote:
Why disable UPDI, anyway? Two obvious reasons are that you want an external hardware RESET signal, or you are so strapped for GPIO that you need just one more pin. A more subtle reason (mine) is that as long as the UPDI interface is enabled, a tiny amount of current is consumed by the UPDI logic which includes a low power oscillator. If you want the lowest possible power consumption in low power modes you must disable the UPDI which stops its oscillator.

 

Since this pin is tolerant to high voltage, maybe you could use it as input to some 5V signal if the MCU is running at 3.3V for example?

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

Since this pin is tolerant to high voltage, maybe you could use it as input to some 5V signal if the MCU is running at 3.3V for example?


Creative idea, El Tangas, but I wouldn't try it. Inside the chip is a comparator which sets the threshold voltage required to activate the alternate function of enabling the UPDI interface. We don't know what this threshold is, and risk tripping it with an externally connected signal. I have unfortunate experience with something like this. A chip I specified had (unbeknownst to me) a similar high voltage override. Unfortunately Murphy's Law kicked in and the chip designer picked a high frequency input signal (SCK on an SPI interface) for this function. Any slight overshoot of this signal put the chip into self-test mode. Until we could re-spin the chip I had to tell all users to put a small capacitor from this pin to ground. 

 

I took a course in speed reading and was able to read War and Peace in twenty minutes. It's about Russia. --Woody Allen

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

Brian Fairchild wrote:

Found it.

 

At 'reset' the pin does come up in uPDI mode.

Just a few days ago I went through the exact same data sheet exercise.  I'm so used to throwing the R and C on the reset pin, but it looks like that's just old habits dying hard.