[Top][All Lists]

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

Re: [bug #61624] [Feature request] Serial/UART UPDI programmers

From: Dawid Buchwald
Subject: Re: [bug #61624] [Feature request] Serial/UART UPDI programmers
Date: Wed, 15 Dec 2021 18:03:48 +0000

Thanks for the detailed explanation. This use case (lousy parallel port 
connection) makes sense, and indeed, this is not applicable to the SerialUPDI 

In fact, with how the NVM model works it’s actually impossible to change fuses 
by accident (like writing to flash at incorrect address, for instance). So 
yeah, I fully support the idea of not implementing safe mode for UPDI.

There is, however, one more thing that mcudude mentioned - at the end of 
programming AVRDUDE would list values of lfuse/hfuse/efuse in its goodbye 
message. It is pretty irrelevant to the modern chips, since they don’t really 
have any of these, they just have array of numbered fuses, so the message is 

What I could do is to add additional feature to SerialUPDI programmer that it 
would list the values of all fuses in the close function. It would still be 
confusing though, because it would list them alongside with incorrect values of 
l/h/efuse. I would still consider this cosmetic “nice-to-have” feature, but if 
you are interested, I can add it on.

Best regards,

> On 15 Dec 2021, at 15:52, Joerg Wunsch <j@uriah.heep.sax.de> wrote:
> As Dawid Buchwald wrote:
>> After some more investigation I concluded that there are actually
>> different scenarios where Safemode is disabled, so I would really
>> leave that for now.
> Just as a side-note, and since there is also one large patch
> regarding safemode which I decided to not apply before 6.4:
> Safemode has been invented by a time when the parallel-port attached
> programming dongle was the standard low-cost programming tool. The
> parallel port's driving capabilities (if no buffers have been used)
> were not very strong, so with a few 10 cm of wires, it could
> occasionally happen that bits might have flipped during an ISP
> transaction. If that flakiness accidentally flipped one of the fuse
> bits, it could result in the AVR losing its clock source, rendering it
> unusable for further ISP sessions.
> Safemode was thus implemented to ensure fuses, at the end of an ISP
> session, were just those they are supposed to be (i.e., fuses from the
> beginning of the session including all requested alterations from -U
> options), giving an option to reprogram them while the ISP session is
> still active. (Fuses only take effect at a reset, so within the ISP
> session, the clock remains what it's been at the start of the
> session.)
> Given that this kind of flakey programming dongles is now basically
> history, I wonder whether it really makes sense to still have Safemode
> active all the time. Other programming tools (like Atmel/Microchip
> Studio) don't do something like that, and I haven't heard of
> accidentally flipped fuse bits lately.
> Instead of completely dropping the Safemode code, I'd propose that
> after releasing 6.4, we might enable it only if so requested for any
> particular programmer by avrdude.conf (and then enable it there for
> all parport and serbb programmers).
> Opinions?
> -- 
> cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sax.de%2F~joerg%2F&amp;data=04%7C01%7C%7C6f97d6468c0349ba105008d9bfda7f1c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637751767415115751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=08OAR9%2By%2FHMWy5ze9%2FcQYN119jX5LFHr1SqtjVjQ2qE%3D&amp;reserved=0
> Never trust an operating system you don't have sources for. ;-)

reply via email to

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