NK65 eeprom compatibility with 128KB and 256KB

[yiancar]

Due to some manufacturing constrains, a large number of NK65s have been made (but not sold) with a F303CB chip.
After contacting ST the Application Engineer has informed me that CB and CC share the same die, but CB is validated to have working Flash up to 128KB. This means that in both versions of the chip, 256KB are addressable but not necessarily functioning.

This workaround asks for the size of the flash memory from the internal register. This means that it will auto adjust to 128KB or 256KB.

This saves adding a whole new chip class "F303xB" that chibios doesn't have, probably because the only difference is the flash size. Downside is that the every time there is an eeprom access an extra cycle is used to read that register. This is the reason I opted to not add it in core.

Description

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[yiancar]

@tzarc could you take a look please?:)

[drashna]

Wouldn't this be better to go into the core? If not now, then later, at least?
Because IIRC, this effects anything with the F303 chip?

[yiancar]

yes it does, I mean I can add it no problem, just let me know if you care about the extra read cycle.
If it was not a define then it could be done dynamically one at startup, to figure out which chip you got and then use that every time.

[tzarc]

I'll assume it's been tested on your end, the change itself looks fine (keeping in mind I'm not familiar with F303) and it's localised to the board in question.
I'd prefer to raise it as a separate PR for core, later, once a thorough look can be cast on it.

[yiancar]

It has been tested yes.
I would say so as well. Maybe the right course of action is make this:

        ifeq ($(MCU_SERIES), STM32F3xx)
        SRC += $(PLATFORM_COMMON_DIR)/eeprom_stm32.c
        SRC += $(PLATFORM_COMMON_DIR)/flash_stm32.c
        OPT_DEFS += -DEEPROM_EMU_STM32F303xC
        OPT_DEFS += -DSTM32_EEPROM_ENABLE

More fine grain.

If people agree on that I can file a separate PR shortly

[yiancar]

Issue has been filed: #10836