AVR-DD datasheet and UPDI chapter discrepancy

[SpenceKonde]

See final comment in #383. The datasheet's electrical properties section and the UPDI section is inconsistent.

I am in the process of composing an email to my inside connection at Microchip about several other matters, both relating to the status of the cores (mainly that 1.5.3 and 2.6.3 are out and seem to be working (need to release 1.5.3 first ofc. That's a critical bug fix to correct a single bug in 1.5.2, where a single-character typo resulted in "burn bootloader" bricking all AVR-DD chips (sorry about that one)), as well as to inquire about a couple of issues that I need Microchip answers about (chief among them the fact that the latest silicon errata and datasheet clarification removed all the clarifications because they were "corrected in the latest datasheet", yet all links to the datasheet point to the preliminary one.
These "clarifications" are at times quite dramatic and of extreme importance, for example, "clarifying" that the flash endurance is 1k W/E cycles, not the 10k originally promised, an d that the ADC and DAC are a little worse than they claimed, so it's of particular importance that when the datasheet clarifications are removed, that the updated datasheet be available!

Though I'm also going to inquire about issues where particularly perverse (yet written without malice) software action appears to be able to impede UPDI functionality, and ask (likely in vain) about when we'll get a bloody die rev for the modern AVRs that would lower the number of unaddressed errata, which hamstring various peripherals to varying degrees.

I will add a question about this discrepancy to the email.

I will update both issues when (if) I get useful answers to the UPDI discrepancy issue. Other issues are documented elsewhere.

[unebonnevie]

Thank you! I think Microchip, after acquiring Atmel, is now aiming to sabotage Atmel's original ATMEGA/ATTINY product lines with AVR128DBxx, which is so hard to use, just like their crappy compiler for their own 8-bit micro-controllers.

[SpenceKonde]

I have to say I disagree with you. AVR was in trouble prior to the 2016 revolution. They had become a backwater while atmel tried (in utter futility) to compete one notch higher up the complexity ladder with the low end ARMs with xMega. xMega was of course a disaster - it had a technical manual (the parts were so complicated they didn't put it all into a "datasheet"), every single peripheral made the modern AVR's TCD look straightforward. [the longest chapter about a peripheral is the TCD one, and I think it is dreadfully terse and would need to be 30-70% longer to not be so confusing. It is absolutely the most complicated peripheral to work with. I don't know if it's internals are the most complicated, but with almost everything happening in another clock domain and needing to sync across that, and all the wackyness, i'd bet that it's either the TCD, or the new ADC on the 2-series and Ex] xMega has the fingerprints of engineers without good product managers with a on their leash all over it. But the net effect was that instead of moving the keeping the best aspects of AVR and upgrading the rest to compete with ARMs, they dropped the best things about AVR (5v operation, general simplicity), and picked up the limited operating voltage range of the ARMs, along with the complicated peripherals and horrific learning curve

They kinda took their eye off the ball to chase that. The classic AVRs are primitive and they were getting no love during the years that Atmel thought xMega was the future - their peripherals suck, every pincount was made totally different from every other one, everything was adhoc, pins appear to have been assigned to peripherals by throwing darts at a package drawing while blindfolded...

I would say that the classic AVRs are harder to use than the new ones, because you can't generalize as much between parts. If you look at the pinouts of the modern AVRs next to eachother.... the mapping of alternate functions to port pins on every non-tiny is exactly the same. Newer parts add mapping options, but don't remove old ones - any peripheral that exists has the same pins (too bad if the pins don't happen to exist, but I think the payoff in terms of only having to learn the pinout once is worth it.

[WestfW]

There's no need to release "bad" products to sabotage a competitive line of microcontrollers after you've acquired a company. You can simply stop releasing new products at all, and gradually increase prices of the existing chips. Sort-of like Microchip has done with the 8051-based microcontrollers that they've acquired. (and let me tell you about the wiz-bang MIPS chip we were going to buy from Palo Alto Semiconductor. Apple bought them, apparently solely for the engineer expertise in the company - no product at all ever shipped. Sigh.)

[SpenceKonde]

Oh, and speaking of ATtiny and ATmega.

In case you hadn't noticed, ATmega as a brand was hustled behind the woodshed way back in 2016 after the 0-series came out. No part since has been named ATmega, and I'd happily wager $250 at 1:1 odds that there never will be another ATmega release. (anyone wanna take me up on this?)

I also would not be surprised if the ATtiny brand is done with the 2-series, and there will never be a further tinyAVR released. I mean the writing is kind of on the wall what the DD-series tanks and artillery parked in the highlands of tinyAVR territory while the Ex-series masses infantry for an even larger assault..... I'm pretty certain of this, but I'd only be willing to risk a hundo betting on that.

[unebonnevie]

@WestfW wrote:
There's no need to release "bad" products to sabotage a competitive line of microcontrollers after you've acquired a company. You can simply stop releasing new products at all,

Yep...That's "sabotaging" :-)

[SpenceKonde]

My man on the inside was less helpful than usual on this matter "On the HV UDPI front it’s all dependent on the amount of energy applied to that pin i.e. voltage * time but I have asked for clarification on the bits and pieces of information that’s scattered on our websites"

In other words, we still don't know for sure how to hvupdi these things without damage.

[SpenceKonde]

Closing issue: we have an official answer - if a profoundly unsatisfying one

[pcfreak1201]

When I'd a look if the MPLAB® PICkit™ 5 is HV-Prog capable, I found this:

3. The UPDI function is on a shared pin that can also be used for GPIO. RESET is on a dedicated pin.
   If GPIO has been selected and UPDI is now desired, an HV pulse is required on the RESET pin to
   reactivate the UPDI functionality.
   This configuration is found on newer AVR devices (AVR DD) and requires an HV pulse of
   approximately V DD + 2 volts. See the device data sheet for the actual value range.

So it looks like Microchip has changed their mind / go away from the 12V pulse...

[SpenceKonde]

I got official confirmation that it didn't need to go as high as well, though inwas told a max of 9.5v and "it really depends on the energy into the cell" or some nonsense like that and that they would attempt to.document thst more clearly......

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Sat, May 20, 2023, 05:38 pcfreak1201 ***@***.***> wrote: When I'd a look if the MPLAB® PICkit™ 5 is HV-Prog capable, I found this: 1. The UPDI function is on a shared pin that can also be used for GPIO. RESET is on a dedicated pin. If GPIO has been selected and UPDI is now desired, an HV pulse is required on the RESET pin to reactivate the UPDI functionality. This configuration is found on newer AVR devices (AVR DD) and requires an HV pulse of approximately V DD + 2 volts. See the device data sheet for the actual value range. So it looks like Microchip has changed their mind / go away from the 12V pulse... — Reply to this email directly, view it on GitHub <#384 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW76LVSVMJWFSAWRUZLXHCGIDANCNFSM6AAAAAATTZ2Q6I> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[PeakeElectronicInnovation]

In case anyone else has a bricked Dx series MCU, and does not have an HV programmer - I just managed to recover mine by powering the circuit via 3V, setting up a second supply of 5.5V, holding 5.5V on the reset pin for about 5 seconds, releasing then immediately reading the MCU via Atmel Studio Device Programming dialog (using Atmel ICE). Shorter "pulses" didn't seem to work (ie < 1s). The read back fuses confirmed UPDI pin had been set to GPIO, changed it back to UPDI and programmed fuses, all ok again yay!