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

NK65 eeprom compatibility with 128KB and 256KB #10804

Merged
merged 2 commits into from
Nov 2, 2020

Conversation

yiancar
Copy link
Contributor

@yiancar yiancar commented Oct 30, 2020

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
Copy link
Contributor Author

yiancar commented Nov 1, 2020

@tzarc could you take a look please?:)

@tzarc tzarc requested review from tzarc and a team November 1, 2020 02:26
@drashna
Copy link
Member

drashna commented Nov 1, 2020

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
Copy link
Contributor Author

yiancar commented Nov 1, 2020

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.

Copy link
Member

@tzarc tzarc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@tzarc tzarc requested a review from a team November 2, 2020 11:34
@yiancar
Copy link
Contributor Author

yiancar commented Nov 2, 2020

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
Copy link
Contributor Author

yiancar commented Nov 2, 2020

Issue has been filed: #10836

@tzarc tzarc merged commit 4b839db into qmk:master Nov 2, 2020
@yiancar yiancar deleted the nk65_eeprom_compatibility branch November 2, 2020 21:42
oscarcarlsson pushed a commit to oscarcarlsson/qmk_firmware that referenced this pull request Nov 2, 2020
* NK65 define hack for 128kb 256kb versions of F303

* Updated to chibios define
ringmaster pushed a commit to ringmaster/qmk_firmware that referenced this pull request Nov 5, 2020
* NK65 define hack for 128kb 256kb versions of F303

* Updated to chibios define
barrettclark pushed a commit to barrettclark/qmk_firmware that referenced this pull request Nov 5, 2020
* upstream/master: (153 commits)
  [Keymap] add brandonschlack userspace and keymaps (qmk#10411)
  [Keymap] add ai03/polaris:mekberg (qmk#10508)
  CLI: Add `qmk clean` (qmk#10785)
  Adds support for XD84 Pro (qmk#9750)
  Freyr refactor (qmk#10833)
  KC60 refactor (qmk#10834)
  [Keyboard] Fixes for PloopyCo mouse and readmes (qmk#10841)
  Enable extrakeys, mousekeys for all VIA keymaps. (qmk#10740)
  Add OLED support for Riblee F411 (qmk#10778)
  NK65 eeprom compatibility with 128KB and 256KB (qmk#10804)
  Add support for Noxary Vulcan (qmk#10822)
  Enable media keys support for Canoe VIA keymap (qmk#10829)
  Phantom refactor (qmk#10805)
  `qmk info`: Add `--ascii` flag (qmk#10793)
  [Keymap] Corrected the dvorak layout for kinesis advantage (qmk#10808)
  [Keyboard] Fix keyboard matrix scan rate with F072 (qmk#10226)
  [Keyboard] nullbitsco/nibble Configurator rework (qmk#10814)
  [Keyboard] VIA Support: Exent 65% (qmk#10797)
  [Keyboard] Add keebsforall/freebird60 (qmk#10774)
  add 65_ansi_split_bs to default community layouts (qmk#10770)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants