Solved: amps bleed off from one 328P-PU to another during sleep.

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

I have two identical ATMega328P-PU chips. Both sleep unless wakened on digital pin 3  (INT 1). One chip has power, the other one does not. The chip with power can send a signal when awake via digital pin 9 (PCINT1) to the digital pin 3  (INT 1) of the second (un powered chip) to wake it.

 

Everything works great. No problems.

 

When I put an ammeter on the power to the chip with power  I see ~ 35mA wake, ~12mA sleep.   If I disconnect either the pin 3 - to pin 9 or the serial RX - to - TX wires my readings are

~0.1mA sleep and ~ 22mA wake. Please keep in mind digital pin 9 is HIGH only when the powered chip is awake. When it sleeps all pins (that are output) are low.

 

I am a beginner so please bear with me if this question is basic.

 

It appears to me even though the second (un powered) chip is not on. some how it can draw amperage from another chip even if the wires connecting are LOW.

 

 

My goal is power savings so obviously a 22mA cost vs. 0.1mA is an issue for me.

 

Any and all suggestions would be great.

 

Thank you all in advance.

 

Attachment(s): 

I am a new AVR programmer. I am learning alone out of books, the Internet, etc. Please excuse me if I ask simple questions. Thanks.

Last Edited: Wed. Sep 27, 2017 - 03:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How does an un-powered mpu "wake up"? 

 

How is the second 328 powered on?   Fet controlled from first 328? 

 

Please show a schematic of your circuit, too many unknowns to answer.....

 

 

Jim

PS, you can just imbed your images using the picture icon above. (two to the left of the smilely face icon)

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

You should "never" connect an unpowered MCU to other circuits with power. The BIG issue that that every GPIO pin (except RESET, which is not a standard GPIO) has input protection diodes to Vcc. If you apply a signal to the unpowered MCU, it will try to start using the power it can get from that input signal through the internal protection diode. Besides the limited current capability of those diodes and the inherent voltage drop, the MCU may not even have time to boot up before the signal goes away. 

 

Thus, it is an all around bad idea. There ARE  other ways of doing it.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

OK, I'll bite:  How do you "awaken" an "unpowered" chip via a signal on a common pin?

 

I kind of question your whole approach.  Let's start with the choice of two microcontrollers, apparently "nearby".  As you have seen, you immediately start adding a lot of complexity, along with board space and cost, versus using a single microcontroller.

 

[We haven't yet seen schematic/wiring diagram/picture.  We haven't seen the complete test programs that show the symptoms.  We don't know language or toolchain or version or optimization settings.  We don't know which clock source the AVR's use.  That said, UART "rides high" when idle and my guess would be parasitic power through the UART.  Obviously, when "unpowered", one can turn off the UART and invoke PRR for it.]

 

Why try to "unpower" the second unit, vs. a deep-sleep mode?

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
Why try to "unpower" the second unit, vs. a deep-sleep mode?

 

Indeed, as just powering on the usart (via PRR) would provide a pin change interrupt to the deep sleeping mpu!

 

Jim

 

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

 I am sorry I was not clear. I am using the Arduino IDE to program. Both MCU sit on their own bread boards (they are "bare bones" with just a crystal and 2 22pF caps). 

 

The second MCU should never power up and does not appear to. Its just that it appears to be robbing power even with out power directly to it. 

 

This came about during my "tinkering"

 

Eventually I will have the two MCUs talking to each other via Serial protocol. For now I wanted to see what was going on should one of the batteries fail in the field. 

 

I am going to try to digest what everyone wrote here. Please keep in mind I am still a beginner.

 

Thanks.

 

Sam

I am a new AVR programmer. I am learning alone out of books, the Internet, etc. Please excuse me if I ask simple questions. Thanks.

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

This is the actual schematic for the two. It shows the pin arrangement. There are no other things attached to either MCU (except for 16MHz crystals, and caps for the crystals).

I am a new AVR programmer. I am learning alone out of books, the Internet, etc. Please excuse me if I ask simple questions. Thanks.

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

As mentioned earlier, this is expected operation. Each gpio pin has protection diodes to vss and vdd. So power is sneaking from your powered avr to the gpio pin of the unpowered avr then via the protection diode to vdd and powering the avr. Solution: set the output low.

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

Thank you!

 

I will do that tomarrow after work.

I am a new AVR programmer. I am learning alone out of books, the Internet, etc. Please excuse me if I ask simple questions. Thanks.

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

AVR_Beginner wrote:
There are no other things attached ...

You do have a common GND between the devices, don't you?

David (aka frog_jr)

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

Frog_jr: no, just what I drew in the diagram. The second MCU is only attached to the 1st via the  3-9 pins and 0-1 pins.   Breaking either of those two lines stops the parasitic amps draw.

I am a new AVR programmer. I am learning alone out of books, the Internet, etc. Please excuse me if I ask simple questions. Thanks.

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

Not having a common gnd is bad juju. Current flows in a loop and it helps to know where it flows. In your case it is flowing where you don’t expect it to.

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

What pin is ever labelled 0 (zero)?

 

Ross McKenzie ValuSoft Melbourne Australia

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

Ross, i dare say it is arduino numbering. This gets confusing when dealing with bare chips.

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

Yes. It's Arduino pin numbers.  Sorry :-(

I am a new AVR programmer. I am learning alone out of books, the Internet, etc. Please excuse me if I ask simple questions. Thanks.

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

Arduino pin 0 is PD0/RXD, pin 1 is PD1/TXD.

Arduino Pin 9 is PB1/OC1A, pin 3 is PD3/OC2B/INT1

 

So that's probably it then.  Even when the powered AVR is asleep, the TXD pin will ride high, so VCC is being provided to the unpowered AVR via PD0/RXD, and (when 'pin 9' is low) GND is being provided via PD3/OC2B.

 

Very bad juju.

 

Answer:  disable the USART on the powered AVR and make it an output low before going to sleep.

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

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

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

... and connect the valid ground pins.

Ross McKenzie ValuSoft Melbourne Australia

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

... and connect the valid ground pins.

And connect the ground pins :)

 

... and >>all<< VCC pins... (i.e. VCC and AVCC)

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

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

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

Yup. That seems to have done it. When both MCUs are connected to VCC and GND this problem goes away even with out mucking with the USART settings. When VCC and GND are not common the second MCU seems to suck amps from the first even though it has no power attached.

 

Thank you all for the help!!

 

I am going to read up more on how these pins and their diodes work and how the UART / USART work.

I am a new AVR programmer. I am learning alone out of books, the Internet, etc. Please excuse me if I ask simple questions. Thanks.

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

Yup. That seems to have done it. When both MCUs are connected to VCC and GND this problem goes away even with out mucking with the USART settings. When VCC and GND are not common the second MCU seems to suck amps from the first even though it has no power attached.

Well, no.

 

Your goal was to test what happens when the battery dies on one of them.

 

What you found was that the unpowered AVR was pulling power from the (asleep) powered one.  The reason is that the USART on the powered one was still enabled in sleep, keeping TXD (pin 1) high, thus powering the unpowered one through the protection diodes on RXD (pin 0).

 

The solution is:

1) disable USART before sleeping, make sure pin 0 is output low

2) make sure any other connected pins are held low

3) ensure all GND pins on both are all connected to the common circuit ground

 

My advice to connect all power pins (VCC and AVCC) was not to suggest that both MCU needed to be connected to the same VCC.  Only the GND need be shared.  If you connect the VCC of the two MCU together, that hardly resembles the system you're trying to test.

 

Bottom line:  If VCC is 'off' i.e. battery dead, the MCU will remain powered >>if<< any of the input pins are held high.  That's what's happening with the USART staying enabled on the other (sleeping, powered) MCU.  You must disable it before sleeping.

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

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

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

joeymorin:

 

Thank you for the correction.

 

Yes, you are right, that is what I am trying to achieve (one battery can die in the field and that MCU will not pull power from the good one).

 

I am gonna set that up and test it as you outlined this evening.

 

Thank you and everyone else for the help!

 

Sam

I am a new AVR programmer. I am learning alone out of books, the Internet, etc. Please excuse me if I ask simple questions. Thanks.

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

Just to further clarify a few things?

 

Are you using Arduino boards plugged into the breadboard, or raw micro chips?

 

If you are truly using raw micro chips, then as mentioned above, look at the data sheet for the micro.

 

All pins labeled Vcc and the AVcc pin need to be connected together, and to V+.

All pins labeled Gnd, and AGnd, need to be tied together, and to Ground.

 

You CAN have a separate V+ supply for the two micros.

 

With directed connected signals between the micros, you MUST connect the Grounds between the two micros.

(There are other ways to connect the micros, through isolated interfaces, but that is a topic for another day.  In that case one doesn't connect the Grounds together.)

 

Back to the power signals:

 

EACH pair of power pins, Vcc & Ground, and AVcc and AGnd, should have a 0.1 uF cap placed across it, as close to the chip as you can place it.

 

While are sprinkling caps around the breadboard, also put one from Vref to ground on both of the chips.

Do not connect the Vref to Vcc.

 

Good luck with your project!

 

 JC

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

It seems to be working right now. I have more testing to do, but so far so good.

 

Thank you everyone for the help!!

 

Sam

I am a new AVR programmer. I am learning alone out of books, the Internet, etc. Please excuse me if I ask simple questions. Thanks.