FTDI Cable powers chip through UART

[James]

Hi all

I though a few here might find this interesting.

I'm currently working on a project using an Atmel ATMEGA324P/V (picopower
variant), the board has no RS-232, only RS-485 (MAX487). I included a header
for TTL serial interface. Was using this header to run some diagnostics on
my firmware via a USB - TTL (5v) serial cable (Don you know the ones). I was
more than a little surprised when the program actually started running and
returning values with the power supply completely disconnected.

Only GND, RX & TX connected on the cable

So through the hardware UART on the AVR I was having it powered and run at
the correct speed (seemingly) using external crystal osc. to deliver a
perfect data stream at 19200 baud.

Measured Vcc @ 1.7v (BOD was not set)

It took me a while to realise what was happening since it was initially
after I'd had the thing running and disconnected power and thought there was
some magical smoke & mirrors buffer in Windows doing some crazy stuff.

Anyone come across this before?

Regards
James













__________ Information from ESET NOD32 Antivirus, version of virus signature database 5042 (20100419) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[JohnnyInBris]

The TX line from the USB to TTL converter is powering the micro through
the input diode to VCC on the micro's RXD input. Not uncommon to see
this as the micro's supply current is quite low.


On 20/04/2010 8:34 PM, James wrote:

Hi all

I though a few here might find this interesting.

I'm currently working on a project using an Atmel ATMEGA324P/V (picopower
variant), the board has no RS-232, only RS-485 (MAX487). I included a header
for TTL serial interface. Was using this header to run some diagnostics on
my firmware via a USB - TTL (5v) serial cable (Don you know the ones). I was
more than a little surprised when the program actually started running and
returning values with the power supply completely disconnected.

Only GND, RX& TX connected on the cable

So through the hardware UART on the AVR I was having it powered and run at
the correct speed (seemingly) using external crystal osc. to deliver a
perfect data stream at 19200 baud.

Measured Vcc @ 1.7v (BOD was not set)

It took me a while to realise what was happening since it was initially
after I'd had the thing running and disconnected power and thought there was
some magical smoke& mirrors buffer in Windows doing some crazy stuff.

Anyone come across this before?

Regards
James













__________ Information from ESET NOD32 Antivirus, version of virus signature database 5042 (20100419) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Don McKenzie]

James wrote:

Hi all

I though a few here might find this interesting.

I'm currently working on a project using an Atmel ATMEGA324P/V (picopower
variant), the board has no RS-232, only RS-485 (MAX487). I included a header
for TTL serial interface. Was using this header to run some diagnostics on
my firmware via a USB - TTL (5v) serial cable (Don you know the ones). I was
more than a little surprised when the program actually started running and
returning values with the power supply completely disconnected.

Only GND, RX & TX connected on the cable

So through the hardware UART on the AVR I was having it powered and run at
the correct speed (seemingly) using external crystal osc. to deliver a
perfect data stream at 19200 baud.

Measured Vcc @ 1.7v (BOD was not set)

It took me a while to realise what was happening since it was initially
after I'd had the thing running and disconnected power and thought there was
some magical smoke & mirrors buffer in Windows doing some crazy stuff.

Anyone come across this before?

Regards
James

Seen a similar thing where a micro powered an LCD through the parallel
data signals, without any VCC connected.

And I am sure I have seen another similar occurrence, but my memory
fades. I'll give myself a bit of think music, and I may come up with it.

I'll bet there are others readers will be aware of.

Cheers Don...



--
Don McKenzie

Site Map: http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
Web Camera Page: http://www.dontronics.com/webcam
No More Damn Spam: http://www.dontronics.com/spam

These products will reduce in price by 5% every month:
http://www.dontronics-shop.com/minus-5-every-month.html

 

[Jasen Betts]

On 2010-04-20, James <dotatdot@tpig.com.au> wrote:

Hi all

I though a few here might find this interesting.

I'm currently working on a project using an Atmel ATMEGA324P/V (picopower
variant), the board has no RS-232, only RS-485 (MAX487). I included a header
for TTL serial interface. Was using this header to run some diagnostics on
my firmware via a USB - TTL (5v) serial cable (Don you know the ones). I was
more than a little surprised when the program actually started running and
returning values with the power supply completely disconnected.

Only GND, RX & TX connected on the cable

So through the hardware UART on the AVR I was having it powered and run at
the correct speed (seemingly) using external crystal osc. to deliver a
perfect data stream at 19200 baud.

Measured Vcc @ 1.7v (BOD was not set)

It took me a while to realise what was happening since it was initially
after I'd had the thing running and disconnected power and thought there was
some magical smoke & mirrors buffer in Windows doing some crazy stuff.

Anyone come across this before?

It's fairly widely known that CMOS logic can be powered through the
protection diodes on it's inputs if the outputs aren't heavily loaded.



--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

 

[kreed]

On Apr 22, 7:02 am, Don McKenzie <5...@2.5A> wrote:

James wrote:
Hi all

I though a few here might find this interesting.

I'm currently working on a project using an Atmel ATMEGA324P/V (picopower
variant), the board has no RS-232, only RS-485 (MAX487). I included a header
for TTL serial interface. Was using this header to run some diagnostics on
my firmware via a USB - TTL (5v) serial cable (Don you know the ones). I was
more than a little surprised when the program actually started running and
returning values with the power supply completely disconnected.

Only GND, RX & TX connected on the cable

So through the hardware UART on the AVR I was having it powered and run at
the correct speed (seemingly) using external crystal osc. to deliver a
perfect data stream at 19200 baud.

Measured Vcc @ 1.7v (BOD was not set)

It took me a while to realise what was happening since it was initially
after I'd had the thing running and disconnected power and thought there was
some magical smoke & mirrors buffer in Windows doing some crazy stuff.

Anyone come across this before?

Regards
James

Seen a similar thing where a micro powered an LCD through the parallel
data signals, without any VCC connected.

And I am sure I have seen another similar occurrence, but my memory
fades. I'll give myself a bit of think music, and I may come up with it.

I'll bet there are others readers will be aware of.

In the 1980s I serviced a CPU board using 6800 CPU that had an 6810
RAM chip.
I noticed that the Ground pin of the chip was completely out of the
socket and wrapped up under the body of the IC.

The system had been working fine for some time leading up to this. (as
it hadn't been touched for a few years, and must have been like this
for a few years).
The only problem it came to my attention for was dry joints on the
power connector to the board which was an obvious fault,
straightforward diagnosis / repair.

I assumed at the time it was due to current flow through internal
protection diodes, or backwards
through pins that were in the right state to pass current reliably via
internal transistors or FETS (whatever was used in this
ancient technology). Power consumption of the device was obviously
low enough for this to work effectively.

Straightening up the pin was done and was returned to service without
any other problems that I recall.

Cheers Don...

--
Don McKenzie

Site Map:            http://www.dontronics.com/sitemap
E-Mail Contact Page:http://www.dontronics.com/email
Web Camera Page:    http://www.dontronics.com/webcam
No More Damn Spam:  http://www.dontronics.com/spam

These products will reduce in price by 5% every month:http://www.dontronics-shop.com/minus-5-every-month.html

 

[John Tserkezis]

Don McKenzie wrote:

Seen a similar thing where a micro powered an LCD through the parallel
data signals, without any VCC connected.

I can second this.

Originally, the idiot who designed it included circuitry to turn the
LCD display off to save power (this was power sensitive application)
but, forgot to buffer the data lines, and drove the LCD directly from
the CPU bus.

Having realised this was a lost cause, the LCD power down functionality
was removed (the boss wasn't going to buy yet another hardware change).

Enter poor bugger (myself) looking at a very intermittent problem,
where everything worked as it should, but somtimes, the LCD display
would dim a bit. Still worked, but dim.
Not being privvy to that part of the design phase, I never knew the
firmware was actually doing it.

Finally put two and two together, I realised that the "unused" LCD
power control circuitry was actually being actuated after all.
Turns out, the internal CMOS protection diodes on the inputs were
enough to power up the LCD display, albeit at less than 5v (around 4.3v
if I recall). That explained that.

I told the new guy working on the firmware about it, and it was
promptly addressed. Turned out the LCD power control routines were
distributed all over the firmware, and for whatever reason, there was no
"global" control of this. Each little section made it's own mind about
whether or not to power up the LCD. Which explained why the original
idiot didn't do it properly the first time around.



Moral of the story I suppose is never get an idiot to fix their own
screwups. If they can screw it up that well to start with, they can
screw the correction up as well.

 

[John Tserkezis]

kreed wrote:

Straightening up the pin was done and was returned to service without
any other problems that I recall.

Heard of a similar case where a 40 pin CPU was not soldered in at all.
There was enough flex in the legs to keep enough conduction happening
with the plated through-holes.

Was in service for some years before it came in for intermittent
faults. After soldering the legs, all was good.