Not all FUSES get written?

[ale3431]

Hi,
I'm trying to program an ATtiny402, in particular I want to use the EEPROM.
I noticed that upon a reset, the EEPROM is not retained, even though I set the FUSES (in Arduino IDE's settings) to not reset the EEPROM.

Looking at the information while uploading the code, the FUSES that get written are only:

• WDTCFG (0x00)
• OSCCFG (0x02)
• SYSCFG1 (0x06)
• APPEND (0x07)
• BOOTEND (0x08)

The configuration bit that specifies whether the EEPROM is retained or not is contained in the SYSCFG0 register (0x05), which is not written.
I'm using Arduino IDE 1.8.13.

Am I missing something or is it a bug?

[SpenceKonde]

This is behaving correctly. You did not read the documentation. It's discussed at length at at least one place possibly two in the documentation, as this is a frequent point of confusion. I'm pretty sure my method is less bad than the alternatives. As it says in the tools subsequently to the right the name of that option, you must do burn bootloader to apply that setting - burn bootloader writes all fuses and clears the flash and - if an optiboot definition is selected - installs optiboot, otherwise it gives you a chip with empty flash and all fuses written. The reason that it isn't among the fuses we write on upload is that it is on the same fuse as the setting to turn updi into reset. That would brick the board if ypu didn't have special, uncommon, equipment. Since one of my rules is that someone should be able to upload arbitrarily bad or malicious code, and no matter what, as long as you only upload, you can always simply upload good code over it, and there shall not be any way for the sketch, no matter how perverse, to interfere with that, to the greatest extent possible on the hardware. Upload also doesn't set a any fuse that doesn't have a menu, because if it's set to something else, you properly did that so we shouldn't undo your work, while burn bootloader writes the default value to those fuses. The bod fuse is also considered "unsafe" on all parts, because if it's in bod reset, it won't talk over updi. And, well, imagine switching to your 3.3v system soldered to a pcb sharing a power rail with max 3.6v parts, and accidentally uploaded with the bod set to 4.3. To make the chip talk updi to unset this takes 4.3v, but that will burn our the 3.3v parts, so desoldering could be needed to unbrick. So that's also considered unsafe. Note that we have to pick the value to write to a fuse and whether to write it without knowledge of the current settings on the device, so we cant have logic like "set or clear the eesave bit on upload, but don't change any other bits." The upload tools want fuse = value, where value is expressed as 0b________ or 0x__. I could with work make serialupdi support that ki d of thing, but that would be more confusing for people, because now the behavior would depend on the upload tool, and that's no good. And yes, of course you can brick the chip with burn bootloader, but people are typically more careful about that, and more likely to double check these and catch accidental settings not changed since previous project you were working on. And it's something you do a lot less often, so there are simply fewer chances to screw up

…

____________ 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 Tue, Sep 26, 2023, 10:08 ale3431 ***@***.***> wrote: Hi, I'm trying to program an ATtiny402, in particular I want to use the EEPROM. I noticed that upon a reset, the EEPROM is not retained, even though I set the FUSES (in Arduino IDE's settings) to not reset the EEPROM. Looking at the information while uploading the code, the FUSES that get written are only: - WDTCFG (0x00) - OSCCFG (0x02) - SYSCFG1 (0x06) - APPEND (0x07) - BOOTEND (0x08) The configuration bit that specifies whether the EEPROM is retained or not is contained in the SYSCFG register (0x05), which is not written. Am I missing something or is it a bug? — Reply to this email directly, view it on GitHub <#1007>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW3RRURFSAUNKVVZCUTX4LOUVANCNFSM6AAAAAA5HZI2DY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ale3431]

Thank you very much!!
I'm sorry to have bothered you with a trivial question fully explained in the documentation.

I think you did a great job indeed, and know that I know this, it makes total sense to me.

[SpenceKonde]

Generally speaking, The documents specified under this section of of the docs https://github.com/SpenceKonde/megaTinyCore#reference-material are the most information rich. Each one of them covers one topic, most of the time in more detail than most anyone needs, (hence enough detail for most anyone), so targeted

The documentation on these cores, I think, needs to be organized better - the main readme file is so long that nobody reads any of the docs. I think the real thing is that the main readme is trying to both a user guide, but also a feature list. It might make more sense to move the "feature list" type stuff to one file, the userguide type stuff that isn't redundant with the Ref or library Readmes into one of those two, and then leave the README proper as basically an index of the documentation, because I think people zone out when the document is that long. A short index page would be less of a wall of text and make it easier to find what they need

[ale3431]

Indeed, that would a good idea. Maybe the documentation is longer and too detailed for someone searching for a quick answer, but it's still better than reading a long README and thinking of having read all there is to it.