I did some investigation and I believe the issue is that the FLASH copy of the .data section (ie. statically initialized values of data) is overflowing into the .nvram section (where scripts etc are stored). This is evidenced by the fact that the .flash_nvram section has VMA address of 0x80040000 but LMA address of 0x80040be4 (on current main). This is from looking at module/teletype.lss after building the firmware.
This isn’t a problem in and of itself (the NVRAM is not using a full 128kB), but it becomes a problem because of how scenes etc are stored here 2. Note that the address of f resolves to 0x80040000.
Everything boots fine the first time and does the first-boot-initialization, overwriting the end of the .data section. So on the next boot, the firmware tries to copy a bunch of statically initialized values from ROM, but the values have been trashed by the re-initialization of scripts.
There needs to be some optimization of what is held in ROM. I’m not familiar with where all the chunky data is, but it’s over by 3kB in the current main branch, so something sizeable needs to be cut.
Please include the hash displayed at startup and the release of the software (e.g. "Teletype v2.0.1 5f838c9")
On current main branch, hash: 0x5acbc24.
What steps are required to reproduce the bug?
Flash the firmware
Boots ok first time, writing the script data
Next boot fails, as a bunch of init values for static variables (saved in ROM) have been trashed.
Help Mode is generally listed in pairs of {name, usage} with usage prepended by 2-4 spaces. It adds up! This indentation could be automatically inserted, rather than stored in a literal string.
Please describe the bug.
As described on lines:
I did some investigation and I believe the issue is that the FLASH copy of the .data section (ie. statically initialized values of data) is overflowing into the .nvram section (where scripts etc are stored). This is evidenced by the fact that the .flash_nvram section has VMA address of 0x80040000 but LMA address of 0x80040be4 (on current main). This is from looking at module/teletype.lss after building the firmware.
This isn’t a problem in and of itself (the NVRAM is not using a full 128kB), but it becomes a problem because of how scenes etc are stored here 2. Note that the address of f resolves to 0x80040000.
Everything boots fine the first time and does the first-boot-initialization, overwriting the end of the .data section. So on the next boot, the firmware tries to copy a bunch of statically initialized values from ROM, but the values have been trashed by the re-initialization of scripts.
There needs to be some optimization of what is held in ROM. I’m not familiar with where all the chunky data is, but it’s over by 3kB in the current main branch, so something sizeable needs to be cut.
Please include the hash displayed at startup and the release of the software (e.g. "Teletype v2.0.1 5f838c9")
On current
mainbranch, hash: 0x5acbc24.What steps are required to reproduce the bug?
Some initial ideas for where ROM can be saved
int, but all data fits inint16_toruint16_t: https://github.com/monome/teletype/blob/main/src/table.h{name, usage}with usage prepended by 2-4 spaces. It adds up! This indentation could be automatically inserted, rather than stored in a literal string.