Are DDs up for low voltage and low power again?

[Floessie]

Hi there,

DBs have this terrible erratum "Increased Current if Vdd falls < 2.1V" which makes them unsuitable for low voltage battery powered devices. Can anyone confirm that this is fixed with the DDs?

Thanks,
Flössie

[Floessie]

@ITDiscovery maybe? I read you have an AVR64DD28, the one which could be a 328P-PU successor if it supported low voltage with low power again.

[ITDiscovery]

I could certainly try it... I do have an AVR64DD28 I can easily test. I guess I run Blink and see how low I can get Vdd to before it croaks...I'll put a scope on PIN_PA7.

[SpenceKonde]

Well, what you need to do, is just have the chip sitting there with current monitoring running some sketch at Vnom=2V.
Then, raise the voltage to 2.5v, and lower it back to 2v. If this bug is present, that should result in a marked increase in power consumption vs a part that has always seen the voltage between 1.9 and 2.1v (though they note that those are not exact thresholds). So, with a good power measuring setup, you should be able to see the lower, correct power consumption as long as it's never seen a voltage higher than that range, then after the voltage excursion above 2.1v, when voltage returns to the nominal 2v, you find that the power consumption is higher, indicating the presence of the erratum.

IMO, someone investigating this should

1. Reproduce it with a DB.
2. Determine under what conditions this increased power consumption persists (ie, if you go into power down sleep mode then, do you still see the extra current? If so, that's a much nastier bug than if it only appears in active mode, and if by some wonderful twist of fate, sleep resets it (since the voltage regulator does change modes in sleep, see datasheet, though they're keeping their cards close to their vest on the details)
3. Determine under what conditions the power consumption will return to the lower value (eg, does a reset pin reset do it? What about a software reset? Or does it take a full power on reset?
4. Tell me the result of your findings for points 2 and 3, so I can update the documentation for the core with this.
5. Now that the behavior is characterized, repeat the above test with a DD to answer this question. Repeat with a DA too, since you've come that far.
6. The anomalous current should be seen only on the DB. If it is seen on any other part, tell me, so I can document it, and tell microchip support that the bug which they said was only on the DBs is present elsewhere so they can add it to the list of bugs that they are going fix in a future revision of the die. I'm not sure the timeline on that, but signs aren't encouraging. If it takes so long that the sun will have exhausted it's hydrogen and expanded to form a red giant (which could happen in just billions of years), that would exterminate all life on earth. I sure hope they get them out sooner than that, because that would probably cause the timeline to slip further - I'm pretty sure Microchip's fabs are located there (though if they weren't, that would explain the lead times, and their reluctance to perform die revs)

Do note that on Dx-series parts, all clock speeds are supported at all voltages within the specified range (1.8-5.5V), because internally the core is not running at Vdd, it's running at Vcore, which is produced by an on-chip regulator from Vdd. I believe that Vcore is very close to 1.8v. On these parts, all pins have a MVIO-like level shifter. MVIO is just the name for breaking one port's level shifter off of that, tying it to a new power rail, and putting a BOD-like detector on it so the pins tristate gracefully if VDDIO2 is too low instead of behaving in undefined ways. This is also why you will notice that you don't get significant shifts in the internal oscillator speed if VDD changes - the voltage the oscillator runs at is Vcore. I think at the very low end of the voltage range, though, it has to bypass the regulator, and it's a problem with that mechanism which leads to this bug.

So what you need to do is not turn the voltage down until it stops working. That doesn't tell you anything (about this at least). You need to compare the current at the very bottom end of the voltage range before and after increasing the voltage to something higher and then returning it to the original voltage. Other factors should be unchanged. The Erratum gives no indication that there is any dependance on the code running on the chip (so as far as it is saying, it doesn't matter if the chip is sleeping, for example - but Microchip/Atmel isn't exactly known for the thorough treatment of the ramifications of silicon bugs (IMO, they treat them as if the die rev were coming out tomorrow)

[ITDiscovery]

Got it...gimme a few days to get it setup...I have a DD and a DB with the same support circuitry...so will be apples to apples.

[ITDiscovery]

Step 1: Burn the bootloader with the IDE 1.8.13 and DxCore 1.5.3 via Serial UDPI at 57.6K (Slow):

DB: AVR128DB, Clk 24MHz, milliseconds: TCB2, BOD: Enabled/Enabled at 1.9v, WDT Timeout: disabled and no delay. Reset is PF6. Startup is 8mS. Bootloader is USART0 at PA0 and PA1. Bootloader entry is default. MVIO is enabled (and these boards have a 3.3V reg to VddIO2). Attach interrupts on all pins. printf is default. Wire is 1x Master or Slave.

DD: Clk 24MHz, milliseconds: TCB2, BOD: Enabled/Enabled at 1.9v, WDT Timeout: disabled and no delay. Reset is PF6. UPDI is PF7. Startup is 8mS. Bootloader is USART0 at PA0 and PA1. Bootloader entry is default. MVIO is enabled (and these boards have a 3.3V reg to VddIO2). Attach interrupts on all pins. printf is default. Wire is 1x Master or Slave.

Step 2: Upload Blink (DB: 1368 bytes, DD: 1288 bytes of code)

Step 3: Using a 2K pot, hook up one meter to measure voltage, and run the "variable" voltage supply through the other meter to measure current (yup...next toy is a bench supply - so this may not meet the needs of the test).

At 4.95V the DB pulled 6.3mA running Blink. At 3.4V it pulled 5.7mA. At about 2.2V the current would fall off to about .3mA and my voltmeter would jump up to 3.8V (because the AVR changed it Resistance I am presuming). A little playing around and I could keep it awake around 2.1V at 4.948mA. I let that sit for 30 secs and then raised the voltage to 2.59V waited 30 secs...back down to 2.08V at 4.923mA.

At 4.95V the DD pulled 5.3mA running Blink. At 3.4V it pulled 4.8mA. At about 2.2V the current would fall off to about .3mA and my voltmeter would jump up to 3.8V (because the AVR changed it Resistance I am presuming). A little playing around and I could keep it awake around 2.25V at 4.339mA. I let that sit for 30 secs and then raised the voltage to 2.59V waited 30 secs...back down to 2.21V at 4.334mA.

I suspect you may feel like that's probably pretty inconclusive. I didn't see any current increase on DB if it went up to 2.6 and back down. One thing I did observe was that as I was dropping the voltage down to the BOD level was the the DB took a lot more voltage to "awaken" and it wasn't very reliable (based on having a scope on the BUILTIN)..usually DB had to get back above 3V before it would fully recover. While the DD couldn't get as low as the DB, it didn't take much (maybe a couple of tenths of a volt) to "awaken" and then it was back to blinken BUILTIN. You sure can't start the chip at the BOD voltage (I tried), and the both DB and DD seemed to expect that voltage to go down really slow.

If you're going for low power apps, DD is the upgrade and the numbers bare that out. Especially given that the DD seemed to me to be more tolerant of bouncing around the 2.5 volts. Neither started up on 2.1V (for DB) or 2.25V (for DD) but would start at 2.5V.

Hope that helps....if there are other measures needed, let me know, as I can typically set them up over a couple of hours on the weekend.

[coburnw]

I was populating an old blank board for a new project and thought i might take the opportunity to solder down the bare minimum of components and firmware to get a sense of the DD32's power usage and to investigate the power errata mentioned by Floessie. Altho the instruments i am lucky to have access to are quite precise, not one has a cal sticker from this century. Take the numbers for what they are worth.

For reference, Microchips DB errata for Rev A1 silicon:
2.2.1 Increased Current Consumption May Occur When VDD Drops
The device may experience increased current consumption of approximately 1.5 mA if VDD drops below 2.1V and is
held in the range of 1.9-2.1V. This will only occur if VDD is originally at a higher level and then drops down to the
mentioned voltage range.

Setup:

• AVR64DD32-I TQFP, Silicon Rev A3. Dec 2022 Mouser buy.
• Board assembled with processor, bypass caps, and led only.
• All fuses unprogrammed.
• SERIAL0 enabled but no offboard connections or activity.
• Five second LED flash on PIN_PA7 for boot indication.
• 500 Hz square wave to PIN_PA3, visually monitored with o-scope to verify run state.
• 1ohm 1% resister used for current measurement

Data:

• Vcc = 3.303 volts, Icc = 0.00461 amps
• Vcc = 2.001 volts. Icc = 0.00435 amps
• Vcc = 3.303 volts, Icc = 0.00459 amps
• Vcc = 1.798 volts, Icc = 0.00393 amps
• Vcc = 3.303 volts, Icc = 0.00460 amps
• Vcc = 1.499 volts, Icc = 0.00317 amps
• Vcc = 3.303 volts, Icc = 0.00462 amps
• Vcc = 1.403 volts, Icc = 0.00107 amps (No square wave on PIN_PA3)
• Vcc = 3.303 volts, Icc = 0.00462 amps

I find it quite interesting (and rather disturbing) how the device resumes operation after the 1.4 voltage cycle without reset. Given the gross drop in current, i suspect the clock simply stops then resumes on vcc rise, with the cpu taking off exactly where it stopped, unfazed. This setup was fairly automated so the voltages snap relatively quickly between values. Im guessing things could get quite ugly if the voltage were to slowly drift between values. In the future, i think i will be a bit more diligent about configuring the brown out detectors.

If i get the opportunity to retest with a db device ill be sure to post the results here.

[Floessie]

Thanks, @coburnw! That's what I was looking for. So the answer is: DDs are not affected by this erratum. 🎉

[coburnw]

So i decided to solder a DB to a bare board and replicate the problem. No luck. I reread Spence's suggestions and formatted the test to more closely follow his protocol with the results posted here. I think there must be more to the errata than what is published. I am open to suggestions.

AVR32DB32-I TQFP, Silicon Rev A1, Aug 2022 Mouser

• Vcc = 0.006 volts, Icc = -1e-05 amps
• Vcc = 2.001 volts, Icc = 0.00483 amps
• Vcc = 2.498 volts, Icc = 0.00505 amps
• Vcc = 2.001 volts, Icc = 0.00483 amps

AVR64DD32-I TQFP, Silicon Rev A3, Dec 2022 Mouser

• Vcc = 0.006 volts, Icc = -0.0 amps
• Vcc = 2.001 volts, Icc = 0.00436 amps
• Vcc = 2.498 volts, Icc = 0.00455 amps
• Vcc = 2.001 volts, Icc = 0.00436 amps

Im assuming that the Silicon Rev referred to in the errata is another name for the value stored in the Device Revision ID Register.

In addition to the data posted i tried noodling around both inside and outside the window, going as high as 5volts. I could get nothing odd to happen. If you are a glass-half-full kind of person, all this might be good news...

[SpenceKonde]

Note that the voltage levels given are not absolute values but typical values
You may not be going low enough.

There is more to every single one of those errata than what they admit to. In some cases, obviously, a lot more than others. The RTC errata on the tinies is a great example of errata that's a lot more perverse than it looks. And that's the errata they admit to!

Sometimes there is a span during which they apparently can't figure out what they want the behavior to be. I've been told that there was an internal debate about whether PWM output should require the pin to be set output or override it. Override won the day, between the release of the DA/B and the release of the DD, and the DD has DIR overrides on their type A and B timers. I dunno if they're backporting it to DA/B - but that change was intended. I think it was intended that the documentation would be changed to reflect that as well during the development process, but I guess nobody told the tech writers. Other times they seem to waffle on whether they will fix the bug or just "clarify the datasheet"

And occasionally there's a bug so embarrassing that they sweep it under the rug, recall the parts, and only the unlucky first movers get the junk parts. No mention of the bug i'm thinking of in the errata or nothing.