Bring supported STM32F4 configs in line with F4x1

[drashna]

Description

The F405, F407, and F446 models use the same weird flash page layout as the F4x1 chips (multiple 16k pages at the beginning). This aligns with the other F4 controllers' following suit.

Verified in the reference manuals for the F405/F407 and F446 that these layouts are correct.

• https://www.st.com/resource/en/reference_manual/rm0090-stm32f405415-stm32f407417-stm32f427437-and-stm32f429439-advanced-armbased-32bit-mcus-stmicroelectronics.pdf (page 75)
• https://www.st.com/resource/en/reference_manual/rm0390-stm32f446xx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf (page 65)

Have tested on the F405RG¹, F407VE F446¹² and G474CE

Types of Changes

• Core
• [?] Bugfix
• Enhancement/optimization

Issues Fixed or Closed by This PR

I created an 870kb firmware for the F405RG (1MB) that soft-bricked. Talking with tzarc, that does run into the currently configured wear leveling area. F4's use a weird layout, which we should take advantage of.

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

Footnotes

1. long delay for USB enumeration after initial flash ↩ ↩²

2. F446 officially has no EFL support in chibiOS. A quick hack to enable the same specs as f411 works. Similar with F407xE ↩

[sigprof]

In general this should be good, but the required LD files are present only for the STM32F405xG case; for other chips we currently don't reserve the second 16K flash sector for the EEPROM backing store, and don't have a proper LD file for the tinyuf2 bootloader.

[drashna]

gonna have to read up more on the memory usage and locations.

[drashna]

Tested with weact g474ce board. However, the weact f446 has a different config (?) that I'm not sure how to configure for.

[sigprof]

The major problem with F446 is that there is no EFL support for that chip in ChibiOS.

[sigprof]

As for the config for the WeAct F446 board, the only change from handwired/onekey/nucleo_f446re is that you need to remove #define STM32_HSE_BYPASS from board.h (Nucleo supplies an external 8 MHz clock signal, for the WeAct board you need to set up HSE with a 8 MHz crystal). The GENERIC_STM32_F446XE board is set up for a 16 MHz HSE crystal, and already defines BOARD_OTG_NOVBUSSENS to make USB work without the VBUS detection circuit on PA9.

[drashna]

Thanks. I figured that it was something simple that I was missing....

And can confirm that these changes work on f446, as well, now.

[sigprof]

This code by itself looks correct, and seems to work. The remaining issues are mostly at the ChibiOS level, so outside of the scope of this PR:

• EFL support for STM32F446 is not implemented in ChibiOS at all.
• EFL support for STM32F405/F407 is incomplete (512K chips are supported only in the master branch at the moment, so the firmware will halt on EFL init).
• During the first startup after flashing the firmware QMK erases the backing store, and the delay caused by that erase triggers some bugs in the USB OTG controller. On F405 (and probably F407) that results in a long delay before the USB enumeration finally goes through; on F446 (and maybe even F405/F407 if using USB HS instead of FS) the USB controller does not seem to recover from that state without a full hardware reset.