qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
18.1k stars 38.93k forks source link

Support for new bluepill stm32f103c6t6a with 32k flash size #15297

Closed eriqadams closed 1 year ago

eriqadams commented 2 years ago

Is there any support for new Bluepill that came with new stm32f103c6t6a chip with 32K Flash size ?, I have tried to burn STM32duino bootloader and flash QMK firmware on to it succesfully but failed to recognize as HID input (Unknown USB Device (Device Descriptor Request Failed)) ?

pcharest2000 commented 2 years ago

Maybe this variant of the bluepill is plagued by the wrong pull up have a look at http://amitesh-singh.github.io/stm32/2017/05/27/Overcoming-wrong-pullup-in-blue-pill.html

eriqadams commented 2 years ago

Maybe this variant of the bluepill is plagued by the wrong pull up have a look at http://amitesh-singh.github.io/stm32/2017/05/27/Overcoming-wrong-pullup-in-blue-pill.html

No, I have checked it came with right resistor value. I have successfully tested to flash using Arduino IDE.

tzarc commented 2 years ago

Probably trying to use emulated EEPROM, but the flash it wants to use doesn't exist.

Try with EEPROM_DRIVER = transient and see if it boots up.

eriqadams commented 2 years ago

I have tried but failed again to be recognized as HID input.

sigprof commented 2 years ago

You may also need to add a board.h file with this:

#pragma once
#include_next "board.h"
#undef STM32F103xB
#define STM32F103x6

(and then maybe fix the resulting fallout if ChibiOS would complain about something missing).

Also you probably need to change the RAM size in the LD script — unfortunately, that's not as simple as it could be; you need to copy both STM32F103x8_stm32duino_bootloader.ld and stm32duino_bootloader_common.ld from platforms/chibios/boards/STM32_F103_STM32DUINO/ld to the ld subdirectory of your keyboard (which you will need to create), then rename STM32F103x8_stm32duino_bootloader.ld to STM32F103x6_stm32duino_bootloader.ld and set f103_flash_size = 32k; there, and then edit stm32duino_bootloader_common.ld and set ram0 : org = 0x20000000, len = 10k there (an even better solution would be to introduce a f103_ram_size variable similar to f103_flash_size and set it in the chip-specific file). Then use this in your rules.mk instead of BOOTLOADER = stm32duino:

OPT_DEFS += -DBOOTLOADER_STM32DUINO
MCU_LDSCRIPT = STM32F103x6_stm32duino_bootloader
BOARD = STM32_F103_STM32DUINO
STM32_BOOTLOADER_ADDRESS = 0x80000000
DFU_ARGS = -d 1EAF:0003 -a 2 -R
DFU_SUFFIX_ARGS = -v 1EAF -p 0003

I cannot actually test this at the moment, because I don't have a STM32F103C6 chip.

eriqadams commented 2 years ago

@sigprof Where should I place board.h in ?

sigprof commented 2 years ago

board.h should be in keyboards/NAME (where you have config.h and the rest of files for the keyboard itself); the ld subdirectory needs to be created there too.

(I also missed an important line in the suggested contents of board.h — please recheck the comment above.)

eriqadams commented 2 years ago

@sigprof I got this error :

./lib/chibios/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.h:127:2: error: #error "USB not present in the selected device" 127 | #error "USB not present in the selected device"

sigprof commented 2 years ago

Hmm, ChibiOS (lib/chibios/os/hal/ports/STM32/STM32F1xx/stm32_registry.h) seems to believe that low-density STM32F10x chips don't have USB; however, the official datasheet for STM32F103C6 says otherwise (even F103x4 parts seem to have USB). This looks like a bug in ChibiOS, and it might not be easy to work around.

You may try to omit the change in board.h, but do the RAM size change in the LD script; not sure whether it would be enough (need to compare the devices in more detail). Does the existing stm32duino bootloader runs on those chips without any modifications?

eriqadams commented 2 years ago

When I omit the change in board.h, I can compile it but got Unknown USB Device (Device Descriptor Request Failed) error.

sigprof commented 2 years ago

Well, then I'm not sure what to do here; probably some low-level debugging and fixing ChibiOS is in order.

eriqadams commented 2 years ago

Is it possible to use stm32-dfu bootloader for STM32F103C6T6A instead of stm32duino since it has built-in USB ?

sigprof commented 2 years ago

No, STM32F103 chips don't have the DFU bootloader in the system memory (they have a bootloader there, but it supports only the serial port). And the bootloader is not the problem here — the problem is apparently that ChibiOS is not set up properly to use the peripherals available in low-density F103 chips.

eriqadams commented 2 years ago

Ok thanks for your assist. I will ask the ChibiOS dev about this bug.

eriqadams commented 2 years ago

Hi, good news from giovani chibios dev that bug have been fixed now.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

long140300 commented 2 years ago

Hi, good news from giovani chibios dev that bug have been fixed now.

can you compile your firmware ? , i was read and still cant compile/use with C6 board

myst729 commented 2 years ago

Any updates? F103C6T6 seems not work.

sigprof commented 2 years ago

Can you test the STM32F103C6 support code from #17853?

Note that you need to use at least board.h and the bootloader-related section of rules.mk from the handwired/onekey/bluepill_f103c6 keyboard in your custom code, because the bootloader parameters also specify MCU_LDSCRIPT = STM32F103x6_stm32duino_bootloader. Also use EEPROM_DRIVER = transient for now, because the proper firmware size check which takes the EEPROM backing store into account is not implemented yet, and with only 24 KiB of flash available for QMK it would be easy to get the backing store overlapping the firmware code.

github-actions[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

github-actions[bot] commented 1 year ago

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know. // [stale-action-closed]