You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 16, 2026. It is now read-only.
This is not really a bug specific to this project, but which should be worked around to prevent some head-scratching.
The Arduino bootloader used in the chip targeted by this project has a bug which causes it to never erase the last flash page. As a result, all writes to that last page can only ever clear bits, never set them. In practice, this means that out of the intended maximum usable flash space of 248kiB, 8kiB are usable only once, and then will forever cause verification failure (and incorrect operation) when the programmed image is larger than 240kiB.
get the Arduino build environment to deduce 8kiB from the usable flash space. From what I can see, the Arduino build environment is extremely rigid (no real way to set compiler options, so I do not expect a way to tweak a chip model's linker mapping), so this seems unlikely to lead anywhere.
add 8kiB of bloat at a fixed address in the resulting image. I think this must be possible in a few inline assembly lines, but so far I am failing to get gcc to comply. The idea would be to fill that bloat with 0xff bytes, so avrdude would ignore them (it looks like it has a feature which never even sends trailing 0xffff words to the chip, so this would take no extra programming time). This way, if the firmware crosses that boundary, the build will fail rather than produce an image that cannot be reliably used.
Maybe someone on this project has the know-how to implement a working solution ?
This is not really a bug specific to this project, but which should be worked around to prevent some head-scratching.
The Arduino bootloader used in the chip targeted by this project has a bug which causes it to never erase the last flash page. As a result, all writes to that last page can only ever clear bits, never set them. In practice, this means that out of the intended maximum usable flash space of 248kiB, 8kiB are usable only once, and then will forever cause verification failure (and incorrect operation) when the programmed image is larger than 240kiB.
I see a few possible workarounds:
avrdudewould ignore them (it looks like it has a feature which never even sends trailing 0xffff words to the chip, so this would take no extra programming time). This way, if the firmware crosses that boundary, the build will fail rather than produce an image that cannot be reliably used.Maybe someone on this project has the know-how to implement a working solution ?