Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too small EEPROM size partitioning on K20x boards #13164

Closed
firetech opened this issue Jun 10, 2021 · 2 comments
Closed

Too small EEPROM size partitioning on K20x boards #13164

firetech opened this issue Jun 10, 2021 · 2 comments
Labels
help wanted question stale Issues or pull requests that have become inactive without resolution.

Comments

@firetech
Copy link
Contributor

firetech commented Jun 10, 2021

(Bringing findings from discussions in #12947 and #9657 to one place.)

Boards based on a K20x MCU currently get their "FlexMemory" partitioned as a 32 byte EEPROM by default, unless partitioned by something else than QMK before. This is becoming an issue since 32 bytes is less than the current EECONFIG_SIZE (35), and out-of-bounds read/write attemps are just ignored in that EEPROM driver. Case in point.

This partitioning can only be changed after a "clear all blocks" command, which will wipe the entire MCU flash. For Teensy boards, this isn't a problem since their bootloader resides in an external chip, but for (at least) Input:Club keyboards, which are using K20x MCUs with the bootloader residing in the MCU's program flash, this would require reflashing the bootloader using e.g. a J-link or Bus Pirate. One thing to note is that the Kiibohd firmware for these boards doesn't seem to use the EEPROM at all, so it's most probably QMK that has partitioned these boards to the 32 byte size.

Just increasing the default EEPROM_SIZE will cause issues for already partitioned boards, since out-of-bounds (read?/)write attempts will cause the EEERDY flag to stay low and therefore causes an infinite loop in flexram_wait().

One way to solve this is to check what size EEPROM the MCU has been set to (in the SIM->FCFG1 register) before the first EEPROM access, and adapt from that size so out-of-bounds accesses are avoided. One can also go further and switch the FlexRAM over to act as traditional RAM (making the same EEPROM driver act as 2048 bytes of transient storage instead) if the partitioned EEPROM size is deemed too small, but that is optional. I have made a working prototype of this behaviour (this block is the optional extra step of going transient), and if that is deemed an adequate solution to the issue, I'll make a PR of this after #12947 has been merged (would cause lots of merge conflicts otherwise).

@stale
Copy link

stale bot commented Sep 11, 2021

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.
For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

@stale stale bot added the stale Issues or pull requests that have become inactive without resolution. label Sep 11, 2021
@stale
Copy link

stale bot commented Oct 11, 2021

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted question stale Issues or pull requests that have become inactive without resolution.
Projects
None yet
Development

No branches or pull requests

1 participant