search

SpenceKonde / megaTinyCore

Arduino core for the tinyAVR 0/1/2-series - Ones's digit 2,4,5,7 (pincount, 8,14,20,24), tens digit 0, 1, or 2 (featureset), preceded by flash in kb. Library maintainers: porting help available!
Other
544 stars 141 forks source link

epprom retained ignored #1012

Closed med1306 closed 9 months ago

med1306 commented 9 months ago

Hello

txs for this core The epprom is erased each time i flash my attiny3216 With power cycle the epprom was ok

SpenceKonde commented 9 months ago

Did you do "Burn Bootloader" like the text in the menu says is required to apply the changes?

No, it does not matter if you are using a bootloader. The programming procedure is to set any fuse except one that if set incorrectly, could prevent further programming from being possible with the same programmer you used to set the fuse (we can't do logic like "Set/clear bit 1 and 2 of this fuse, but leave the rest unchanged "- that requires the program doing the upload know what the value of that fuse is now. We don't have that feature on serialupdi, and it wouldn't change things if it could because we couldn't change that behavior for just serial UPDI Unfortunately, to my great dismay, they placed the EEPROM retain bit on the same fusebyte that UPDI disable bits are located at. So we don't set those on upload because a single casual upload if you forgot to reset the tools submenus to match the board you connected could brick the board. Dangerous fuses are only set upon "burn bootloader" which initializes all fuses, even ones we don't change normally (these are not written on upload, only non-dangerous, fuses that we use (reasoning being if the non-dangerous, unused fuses are set,you probably did that manually and would be unhappy if we undid that on every upload)

SpenceKonde commented 9 months ago

See exact same question asked by someone else last week https://github.com/SpenceKonde/megaTinyCore/discussions/1007

med1306 commented 9 months ago

Sory for the redondant question it work perfectly now.

Again great txs to all your works on megatiny / dxcore and the amazing serialupdi way for programming. For your information i flash a board far away from computer (50m) with SerialUpdi over RS-422 lines with galvanical isolation. the usb/uart was a FT234x the digital isolator was ISO7242 the RS-422 driver was MAX14789 a 74LVC2G3157 was use for auto UART or UPDI mode

SpenceKonde commented 9 months ago

Great! Glad that sorted things out.

Got any suggestions on how I could have improved the interface there so that it would have been clearer? It's definitely our MFAQ, but I have no ideas on how to clarify this further.... I think what throws a lot of people off is that the option says "Burn Bootloader" when not using a bootloader. I'd love to have that menu option say something different, but hardware packages aren't allowed to do that; (in common with classic AVRs) burn bootloader (if there is one) also does the dangerous fuses. Which on classic AVR were generally "all of them", so for consistency, classic AVR never writes any fuses except on burn bootloader on my core the official cores and all third party cores I know of.

That was what we did here originally - no fuses set except on burn bootloader. But 50% of our issues that were being opened were people with 20 MHz selected who had the fuses set to 16 MHz or vise versa. So we had to start setting OSCCFG on all UPDI uploads, because that was clearly a major pain point and I couldn't get any work on anything else done.. I then noticed that the failure mode the BOOTSIZE/BOOTEND. I then noticed that "gee, if you upload a sketch via UPDI onto a board with optiboot, it trashes optiboot, but the sketch doesn't run either" - it was guaranteed not to work (well, unless you never enabled interrupts). I didn't see any good coming from that, so bootsize was added to the list, and then I realized that hardly any of the fuses could ever interfere with reprogramming, so why don't we set them? (every menu option that requires burn bootloader to apply generates questions like this). We write every safe byte to of fuses that the core has a menu for (all the ones we don't are at their default setting (as in, core default value for fuses unused by the core is the same as microchip's default value for those fuses) on burn bootloader, thus if they have changed, you changed them, probably for a reason, and we shouldn't go undoing that on upload, while the intent of burn bootloader is that it should reinitialize the chip into a clean state,