Add KPrepublic BM16A v2 #19194
Add KPrepublic BM16A v2 #19194
Conversation
| Enter the bootloader in 3 ways: | ||
|
|
||
| * **Bootmagic reset**: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard | ||
| * **Physical reset button**: Briefly press the button on the back of the PCB - some may have pads you must short instead |
There was a problem hiding this comment.
Does just pressing RESET actually work if the firmware is corrupted? It may seem to work when some version of QMK is running because of this code in boardInit(); but the unmodified stm32duino code does not set up the BKP->DR10 register to enter the bootloader on a single or double reset.
Apparently the PCB has two pairs of pads that can be shorted that control the BOOT0 and BOOT1 (PB2) inputs (as far as I was able to infer from looking at the PCB photos in the shop — the bottom side photo has lower quality):
BOOT0 is mostly useless on F103, but BOOT1 may be used as the “force bootloader” input (generic_boot20_pc13_fastboot.bin behaves like that). But that should be tested on a real PCB.
There was a problem hiding this comment.
I'm guessing this board is using fastboot as it doesn't immediately appear as Maple 003 when plugged in like my Bluepill does.
I've got no clue on the other stuff.
| "cols": ["B1", "A3", "B0", "B4"], | ||
| "rows": ["A8", "A9", "B5", "B3"] | ||
| }, | ||
| "processor": "STM32F103", // GD32F303CCT6 |
There was a problem hiding this comment.
Note that this configuration limits the usable flash size for the firmware to 56K due to the default MCU_LDSCRIPT = STM32F103x8_stm32duino_bootloader; although I'm not sure that KPrepublic won't “optimize” the hardware in some further revision to use a smaller chip.
Also did you check that the EEPROM emulation behaves properly with this configuration? F103x8/xB chips have 1K flash sectors, but F103xC and larger chips have 2K flash sectors. Apparently the default EEPROM driver for STM32F1xx is now wear_leveling/embedded_flash, and the EFL code in lib/chibios/os/hal/ports/STM32/STM32F1xx/hal_efl_lld.c does not perform any autodetection for the flash page size, therefore it probably does not work correctly when the real chip does not match the compile-time configuration. (This problem does not affect the stm32duino bootloader, because it reads the flash size register and detects the flash sector size from that info, so it should work with all F103 chips with single bank flash.)
Adding board.h with
#pragma once
#include_next <board.h>
#undef STM32F103xB
#define STM32F103xEmay be enough to fix the problem (assuming that KPrepublic would stick to using the GD32F303CCT6 chips on this board and won't downgrade to GD32F103CBT6 or something like that).
(Specifying STM32F103xE should be safe, because the code in platforms/chibios/drivers/wear_leveling/wear_leveling_efl.c support flash size detection for STM32F1xx to determine the backing store location; but that code relies on the ChibiOS EFL driver to get the flash sector size, and that part can be configured only during compile time on STM32F1xx.)
There was a problem hiding this comment.
EEPROM does seem to work; the RGB Matrix settings persist and it boots up with the correct effect and HSV after changing it.
github-actions
bot
added
the
via
Description
New version of BM16A with an F103 clone and RGB matrix. Comes with VIAL preinstalled.
Maybe should split up
kprepublic/bm16ainstead?Types of Changes
Issues Fixed or Closed by This PR
Checklist