Add flash size suffixes to STM32 MCUs

[fauxpark]

Description

Prep work for Arm size check support. And it's good to have these documented either way.
Should not affect anything as mcu_selection.mk detects based on findstring.

Ones marked with x? I am not sure of and would appreciate anyone with one of those boards to confirm, and I'm also unclear whether the Planck and Preonic use the 128kB F303 or the 256kB like the Proton C.

Needs confirmation:
candybar @TerryMathews ✅

handwired/ck4x4 @awkannan ✅

planck/ez @jackhumbert
planck/rev6
preonic/rev3

retro_75 @zvecr ✅

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.
• 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).

[skullydazed]

There are two PCB's that are otherwise identical, one with an xC and one with an xB. Given supply chain issues for the xC and xB I think we'll see this with other boards in the future.

[drashna]

That's ... a mess.

Would it be better to assume the smaller amount, even if that isn't accurate for every board?

[TerryMathews]

On some MCUs, the smaller amount is quite small (64KB). QMK barely fits into that space, and some options have to be turned off to get there.

[tzarc]

Probably exacerbated now with @awkannan using APM32's due to supply chain issues of STM32's.

[TerryMathews]

Candybar is x8.

[drashna]

I can check the planck boards, at the very least.

[fauxpark]

@drashna the thing is, as Skully mentioned above with the Clueboard 60, that Jack may have used the xC and xB interchangeably for the OLKB boards, which means it's basically impossible to get an accurate reading for some percentage of them. I guess we have two options here: split those keyboard directories into two further subprojects, for 128kB and 256kB, or leave off the suffix altogether (which in my WIP code will make check-size throw the same message it does already for Arm).

[noroadsleft]

So, tonight I learned that including the suffixes prevents qmk_compiler from doing Configurator builds, because the compiler doesn't recognize the MCU if the suffix is included.

The keymap attached to qmk/qmk_configurator#664 is fully valid, but Configurator can't compile it:

* Sending wete:default_93c5307 with LAYOUT_ansi_rhnp
* Received job_id: 2235e61e-fbb4-4283-9d5a-bb9725854399
* Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
* Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
* Finished:
QMK Firmware 0.7.171
WARNING: Some git submodules are out of date or modified.
 Please consider running make git-submodule.

Making wete with keymap default_93c5307

tmk_core/chibios.mk:38: lib/chibios-contrib/os/common/startup/ARMCMx/compilers/GCC/mk/startup_stm32f0xx.mk: No such file or directory
tmk_core/chibios.mk:40: lib/chibios/os/hal/hal.mk: No such file or directory
tmk_core/chibios.mk:50: lib/chibios-contrib/os/hal/ports/STM32/STM32F0xx/platform.mk: No such file or directory
tmk_core/chibios.mk:83: lib/chibios/os/hal/osal/rt/osal.mk: No such file or directory
tmk_core/chibios.mk:85: lib/chibios/os/rt/rt.mk: No such file or directory
tmk_core/chibios.mk:91: lib/chibios/os/common/ports/ARMCMx/compilers/GCC/mk/port_v6m.mk: No such file or directory
tmk_core/chibios.mk:93: lib/chibios/os/hal/lib/streams/streams.mk: No such file or directory
makek'.  Stop.
Makefile:560: recipe for target 'wete:default_93c5307' failed
Make finished with errors
make: *** [wete:default_93c5307] Error 1

qmk_compiler only recognizes the following as valid options for MCU in rules.mk:

• cortex-m0
• cortex-m0plus
• cortex-m3
• cortex-m4
• STM32F042
• STM32F072
• STM32F103
• STM32F303

[fauxpark]

We should change this check to match, then. Something like:

if mcu.startswith(ARM_PROCESSORS):

?
https://stackoverflow.com/a/6531678

And I also notice the Arm Teensy MCUs haven't been added yet.

[noroadsleft]

@skullydazed, thoughts?

[noroadsleft]

For posterity:

Wete: STM32F072CBT6 (source)

[tzarc]

Possible solution for qmk_compiler: #8256

% make wete:default:dump_vars | grep MCU=
MCU=cortex-m0
% make matrix/noah:default:dump_vars | grep MCU=
MCU=cortex-m4

[stale]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[yiancar]

Hello!
Just to also say as we are going into the trouble of doing all this, adjusting the linker script to reserve memory for the emulated eeprom is also a good idea

[sigprof]

There is actually another issue here — not all MCUs from the same series, but with different flash sizes, are really compatible. One example came up today in Discord: the STM32F303RET7 chip does not work with the firmware built for STM32F303xC (which is what QMK assumes for MCU = STM32F303 currently). It was possible to make it work by adding a board.h file with this:

#pragma once
#include_next "board.h"
#undef STM32F303xC
#define STM32F303xE

The main problem in this case is that there are significant differences in the USB controller of STM32F303x[BC] and STM32F303x[DE] chips, and the code compiled for one chip does not work on another.

Another series which has significant differences between chips with different flash sizes is STM32F103 — in this case there are 3 posssible variations (medium-density, high-density and XL-density devices; low-density devices have ≤32K flash and can probably be ignored); although in this case the USB implementation seems to be identical, and the main difference is the flash organization and the presence of some additional hardware like DAC or extra timers.

Looks like this PR does not attempt to deal with this part of the problem.

[tzarc]

It might be that we need to provide a secondary board.h much like what you've specified in order to pick up exact models of MCU.

I think for the reasons you touched upon we should probably be leaning towards providing ldscripts along with however the MCUs get configured, as well as an appropriately-written emulated eeprom driver, such that the ldscripts reserve a portion of the flash for eeprom usage. This will allow for flash sizing guarantees as well, instead of guessing and masquerading as a different part.

F4xx's will likely benefit from this as well in future, as they need to have the emulated eeprom situated early in the flash space, purely from the perspective of not wasting 128kB on the last sector.

[sigprof]

For F4xx wasting a 128K sector is not the only problem — if you look at the flash memory characteristics in the datasheet, you will see that for a 128K sector even the best (x32 parallelism) typical erase time is 1 second (and the maximum erase time is then 2 seconds), and these erases will happen during some emulated EEPROM writes. (Erase times for 16K sectors are not the best too — 250 ms typical, 500 ms max).

[jackhumbert]

Jack may have used the xC and xB interchangeably for the OLKB boards, which means it's basically impossible to get an accurate reading for some percentage of them.

I know this isn't the only issue here, but I don't know of any OLKB boards that weren't built with STM32F303CBT7 (128k), and I can't find any BOM where a substitute was specified. And just for posterity, the Proton C used STM32F303CCT6 (256k) in both runs.

[yiancar]

Just to add my experience here, building code with the CC option in mind and flashing it on the CB chip can cause problems. This is because the with the CC code the eeprom emulation is at a region that does NOT exist in the CB chip.
Now saying this, it works because the die seems to be the same. IE the flash is there but possibly not tested/not guaranteed to work.

TL;DR running CC code on CB chips works, this is just pure luck.