Configuration and User Fuses

[Dlloydev]

From the ATtiny datasheets, I've noticed it says

When writing the fuses write all reserved bits to ‘1’

I've only been working with fuse 5, but have noticed that reserve bits are read as 0.

Not sure if this could be an issue or future issue?

At Microchip, (reply#6) they have reserved bits as 1.

At Arduino, there is an unresolved issue relating to fuse 5. I'm suspecting that the Arduino issue is with reserved bit(s) set to 0.

[SpenceKonde]

The treatment of unused fusebits is not controlled by the core, it is controlled by avrdude, the tool used to read and write from the parts.

It now reports unused bits as 0, even though they are read from the chip and written as 1. This was changed from the old behavior, where they were reported as 1, as I recall a few years back. It was not a popular change, as far as I can tell, and caused a considerable amount of frustration and irritation. Though I have not dealt with him in person, I get the impression that the author and maintainer of avrdude is - maybe not the easiest maintainer to deal with. and tends to be certain that his design decisions were the right ones (and, really, I'm not sure I'm qualified to say they're not)

But we must go to war with the upload tool we have, not the one we want. The core configuration and avrdude,conf included with it should not produce any avrdude warnings other than the one about flash and boot (which nobody seems to know how to fix and does not interfere with programming, and is shown with every one of these new style parts (btw - the term "megaavr" is going to be dropped from documentation soon, as it is a confusing term that seems to have just bubbled out of arduino-land, and is not an appropriate or official term for parts with the new style peripherals!). If it DOES produce warnings about invalid fusebits, please create a new issue and list what parts and under what conditions it generates that message, as that is an issue which needs to be fixed ASAP.

[Dlloydev]

Thanks for your reply,

I haven't noticed any discrepancy from avrdude's command line text for fuse 5, i.e. -Ufuse5:w:0b11000101:m which would result in the serial monitor command Serial.println(FUSE.SYSCFG0, BIN); reporting 11000101.

I've noticed the "megaavr" 0-series family datasheet says reserved bits for fuses need to be 0, but the tinyAVRs 0 and 1 series independent datasheets all say reserved bits for fuses must be set to 1. In the future, if I use any of these tinyAVRs in a noisy environment (like part of the electronics built into a portable generator), I could easily edit the command line to set any reserved fuse bits. Otherwise, I'm not really concerned with it.

Regards,

D. Lloyd

On 2020-04-29 08:08, Spence Konde (aka Dr. Azzy) wrote:

The treatment of unused fusebits is not controlled by the core, it is controlled by avrdude, the tool used to read and write from the parts.

It now reports unused bits as 0, even though they are read from the chip and written as 1. This was changed from the old behavior, where they were reported as 1, as I recall a few years back. It was not a popular change, as far as I can tell, and caused a considerable amount of frustration and irritation. Though I have not dealt with him in person, I get the impression that the author and maintainer of avrdude is - maybe not the easiest maintainer to deal with. and tends to be certain that his design decisions were the right ones (and, really, I'm not sure I'm qualified to say they're not)

But we must go to war with the upload tool we have, not the one we want. The core configuration and avrdude,conf included with it should not produce any avrdude warnings other than the one about flash and boot (which nobody seems to know how to fix and does not interfere with programming, and is shown with every one of these new style parts (btw - the term "megaavr" is going to be dropped from documentation soon, as it is a confusing term that seems to have just bubbled out of arduino-land, and is not an appropriate or official term for parts with the new style peripherals!). If it DOES produce warnings about invalid fusebits, please create a new issue and list what parts and under what conditions it generates that message, as that is an issue which needs to be fixed ASAP.

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].

Links:

[1] https://github.com/SpenceKonde/megaTinyCore/issues/179#issuecomment-621161249 [2] https://github.com/notifications/unsubscribe-auth/APEMFPNLDF3Q7I4SEJMVU4DRPAKFDANCNFSM4MTJ532Q

[SpenceKonde]

Huh! Okay then - Do you know if writing the wrong value to unused or reserved fuse addresses actually does anything? I was under the impression that the chip will ignore whatever you write to unused fusebits, and report back a fixed value for them. Leading me to wonder under what circumstance writing arbitrary values to reserved fusebits would be a problem. The specifications regarding how they are to be written being only applicable if there was some future part and the programmer didn't bother to check the signature bytes - in which case they deserve whatever they get - just like with unused bits in registers, my impression was that their goal was to try to ensure that peoples code didn't inadvertantly break on future parts that added newly used fields. Are you aware of any instances where setting unused bits to the wrong thing can result in bad behavior, and this wouldn't have been caught by checking sig before programming?

Well, good to see that Microchip had the organization to have maintained consistent product behavior while they managed the tinyAVR 0-series and 1-series and megaAVR 0-series parts right around the merger, right?

[Dlloydev]

Well, not sure if there would be any consequences (probably none). Unfortunately, the reason for publishing that the reserved fuse bits "must" be written as 1 is only known at Microchip. I found a similar topic [3] (old) from TI's support forum, a community member posts:

If the reserved bits contain a 'must be written as ...' tag, you should respect this (sometimes, a bit has a meaning but not a usefule one, only a destructive one, so it isn't documented). Other reserved bits have no effect at all, but may get an effect on other devices or later implementations. If it is marked as r/o, then it doesn't matter what you write to thsi bit.

https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/163422

Yep, I love Microchip's newer products ... I'm hooked on those tinyAVRs thanks to your hard work in developing and maintaining the megaTinyCore!

D. Lloyd

---

On 2020-04-30 01:54, Spence Konde (aka Dr. Azzy) wrote:

Huh! Okay then - Do you know if writing the wrong value to unused or reserved fuse addresses actually does anything? I was under the impression that the chip will ignore whatever you write to unused fusebits, and report back a fixed value for them. Leading me to wonder under what circumstance writing arbitrary values to reserved fusebits would be a problem. The specifications regarding how they are to be written being only applicable if there was some future part and the programmer didn't bother to check the signature bytes - in which case they deserve whatever they get! Are you aware of any known instances where this can cause bad behavior?

Well, good to see that Microchip had the organization to have maintained consistent product behavior while they managed the tinyAVR 0-series and 1-series and megaAVR 0-series parts right around the merger, right?

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].

Links:

[1] https://github.com/SpenceKonde/megaTinyCore/issues/179#issuecomment-621628031 [2] https://github.com/notifications/unsubscribe-auth/APEMFPM7JC2PMGNCMCOLQYTRPEHANANCNFSM4MTJ532Q [3] https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/163422