avr-chat
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-chat] XMega PDI_DATA and PDI_CLK must be balanced?


From: Bob Paddock
Subject: [avr-chat] XMega PDI_DATA and PDI_CLK must be balanced?
Date: Tue, 31 Mar 2009 12:16:07 -0400

I'm doing a my first design with a XMega, there are sections about
the PDI interface I'm not clear on.  In AVR1005 we can read:

"5.1 Hardware design requirements to make PDI work

The PDI interface is a synchronous half-duplex UART interface. The two lines,
PDI_DATA and PDI_CLK, must therefore be balanced. If you place a strong pull-up
and decoupling cap on the PDI_CLK, which is also the Reset line, the
clock and data
will no longer be synchronized correctly. Therefore, during
development you should
remove any pull-up and decoupling capacitors. This also applies if using the PDI
interface for in-system programming the XMEGA in production."

I can consider removing my external pull-up resistor (can not do much
about the internal pull up resistor) on my development board.  However
that last line is non-sense.  I'm supposed remove the resistor
and put it back on thousands of production units?

My first thought was to put a pull up and small cap on the PDI_DATA line
to balance out the fact that PDI_CLOCK/Reset# goes several places.  Alas
this won't work, or at least has side effects I don't want.  PDI_DATA has
an internal pull down when PDI is enabled, see section 29.3.1 of XMega A manual.
Does this mean the input pin is floating at all other times?  That can't be
good.  Pull up on PDI_DATA also slows down start up time by 100us, that
I do not want.

A pull down on PDI_DATA seems wise to me in a electrically noisy environment
like mine.  This defeats the pull-up/cap balance idea.

Are PDI_CLK/PDI_DATA really to the point they have to be treated
as LVDS like matched length signals?  This seems unlikely given the programmers
they are likely to be hooked up to, like the JTAG-MKII, or other programmers
supported by AVRDUDE.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]