Add generalised support for stm32 f103 to simplify bluepill based boards #5669

zvecr · 2019-04-20T21:03:14Z

Description

Similar to how the Proton C support was integrated into the core of the firmware, the aim is to provide a solid base for bluepill boards. The main goals are to minimise the amount of configuration by just requiring the MCU (and maybe the bootloader type) to be set.

Types of Changes

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

noroadsleft · 2019-04-20T21:09:37Z

If I'm reading this right, this extends the STM32 support so quantum/stm32 gets a subdirectory for each supported MCU (F103, F303, etc.) and sets up the defaults that are appropriate for it, correct? (I'm not really familiar with this area of the codebase.)

If so, I like this change. Anything that helps boost STM32 adoption (lowers the barrier of entry, eases integration with QMK, etc.) is good by me.

zvecr · 2019-04-20T21:17:34Z

Correct, it should help reduce the duplication within the code base by providing those defaults.

As bluepill is the same width (slightly longer) as a pro micro, but more importantly a similar price, I can see it as a potential successor. Its not quite a Proton C, but at less than $2 its a solid alternative when designing a PCB.

drashna · 2019-04-28T05:48:05Z

@zvecr DFU_ARGS is for passing along arguments to the dfu programmer when you flash from command line. You can see how and where they are implemented here:

qmk_firmware/tmk_core/chibios.mk

Lines 237 to 238 in 68fad7b

    
           dfu-util: $(BUILD_DIR)/$(TARGET).bin cpfirmware sizeafter 
        
           	$(DFU_UTIL) $(DFU_ARGS) -D $(BUILD_DIR)/$(TARGET).bin

Understand use of cannonkeys\ortho48 linker setup
What do you mean by that?

zvecr · 2019-04-28T22:09:36Z

@drashna I understand the concept of the option DFU_ARGS but not what DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave is doing for the proton_c and if it applies to blue pill.

ortho48 has a STM32F103x8_stm32duino_bootloader.ld file and has the following rules.mk config

# GENERIC STM32F103C8T6 board - stm32duino bootloader
OPT_DEFS = -DCORTEX_VTOR_INIT=0x2000
MCU_LDSCRIPT = STM32F103x8_stm32duino_bootloader
BOARD = GENERIC_STM32_F103

Makes me think there should be something like BOOTLOADER = stm32duino for this case where is configures the above? Any idea @awkannan

awkannan · 2019-04-29T13:36:21Z

we can use DFU_ARGS to properly pass the correct dfu-util parameters for bluepills

We need these:

-d 1eaf:0003 -a2 -R

If the stm32duino bootloader is present, -a 2 exposes 0x8002000 as the starting flash zone, and -R will reset into the normal firmware at the end of flashing

zvecr · 2019-05-02T00:09:21Z

@awkannan Awesome, thanks for that info. Whats your view on the BOOTLOADER = stm32duino idea to configure your suggestions?

That way, bluepill support is basically a 2 liner

MCU = STM32F103
BOOTLOADER = stm32duino

quantum/mcu_selection.mk

drivers/boards/GENERIC_STM32_F103/board.mk

quantum/stm32/STM32F1xx/chconf.h

zvecr · 2019-06-30T23:27:58Z

Currently the rules.mk file is cut down to only the following,

# MCU name
MCU = STM32F103

# bluepill (with stm32duino bootloader) overrides
OPT_DEFS = -DCORTEX_VTOR_INIT=0x2000
MCU_LDSCRIPT = STM32F103x8_stm32duino_bootloader
DFU_ARGS = -d 1eaf:0003 -a2 -R
DFU_SUFFIX_ARGS ?= -v 1eaf -p 0003

Just need a decision if BOOTLOADER = stm32duino is overkill or if the above is acceptable.

yanfali

---How hard would it be to add stm32f3xx support? I have a couple of bluepills in a draw I could use to test.--- My bad, I see you already added it?

zvecr · 2019-07-01T20:37:34Z

@yanfali We currently have STM32F303 done in the same way for the Proton C, and I would been keen to do it for some of the other popular MCU. There will always be a place for the obscure, but reducing the duplication for something like the Teensy 3.2 can provide a ton of benefits.

yanfali · 2019-07-01T23:34:54Z

OK, just for posterity's sake. Turns out there are some chinese clones for STM32 chips in the CS32 family. They are almost perfectly compatible, except they have a different chipid which is the same as chips in the F3 family from STM. So stlink doesn't officially support them. However if you follow this issue: stlink-org/stlink#756 you will find a commit which will allow you to use st-flash on these chips and be able to follow instructions like the ones from cannonkeys to flash them with QMK and stm32 boot loader.

drashna · 2019-07-02T02:06:34Z

Yeah. I know that the Planck Rev6, Planck EZ, and Preonic Rev3 use this method already.

yanfali

Tested on cs32 bluepill clone boards, registers as one key keyboards. shorting pins produces expected 'a'

yanfali · 2019-07-04T04:18:55Z

tested this on a blackpill. works perfectly

yiancar · 2019-07-05T14:24:46Z

Can you confirm what -R in dfu actually resets. it didnt work for me...

zvecr · 2019-07-05T14:29:06Z

-R from the man page,

Issue USB reset signalling after upload or download has finished.

~~I will have to test my end to confirm the behaviour as I cannot remember seeing mine reboot.~~ MCU reboots after flashing fine on my machine, Ubuntu 19.04 and dfu-util 0.9.

yiancar · 2019-07-05T14:35:45Z

Yes but it didnt work on me so:)

zvecr · 2019-07-05T14:39:14Z

@yiancar I'm not sure I can help if you don't list your environmental differences, so we can start to figure out the issue.

@yanfali Do you also see this issue?

yiancar · 2019-07-05T14:47:46Z

im on mac dfu-util 0.9 which bootloader u using?

zvecr · 2019-07-05T14:50:24Z

stm32duino as mentioned above, with the flashing steps provided at https://docs.cannonkeys.com/flashing/

yiancar · 2019-07-05T14:51:05Z

ah sorry, yes thats what I got as well:)

yiancar · 2019-07-05T15:23:49Z

Might be the MacOS

yanfali · 2019-07-05T15:42:48Z

@zvecr mine doesn't reset, I usually just unplug.

zvecr · 2019-07-05T15:54:31Z

I would then consider it a best effort until the exact circumstances can be worked out.

drashna · 2019-07-30T07:09:17Z

Is this ready to ship, as is? Or should it wait?

zvecr · 2019-07-31T23:08:00Z

There might be some extra stuff, as @yanfali sent me a PR to add some docs, and given the extra time with my bluepills, I was thinking of some suggested changes to the defaults.

yanfali · 2019-08-01T00:17:22Z

Yeah, -R did not work on the clones. Sorry it took me a while to notice this question.

drashna · 2019-09-21T07:04:26Z

There are some merge conflicts here.

zvecr · 2020-02-27T22:13:57Z

Most of this PR has now been reimplemented, missing bits are just default central conf files. This will be tackled separately.

noroadsleft mentioned this pull request Apr 28, 2019

Satisfaction75 i2c fix and VIA layout #5726

Merged

10 tasks

zvecr changed the title ~~Refactor of onekey to support multiple development boards~~ Add generalised support for stm32 f103 to simplify bluepill based boards May 29, 2019

zvecr mentioned this pull request May 30, 2019

Refactor of onekey to support multiple development boards #6017

Merged

13 tasks

drashna reviewed Jun 23, 2019

View reviewed changes

quantum/mcu_selection.mk Show resolved Hide resolved

awkannan reviewed Jun 26, 2019

View reviewed changes

drivers/boards/GENERIC_STM32_F103/board.mk Outdated Show resolved Hide resolved

awkannan reviewed Jun 26, 2019

View reviewed changes

quantum/stm32/STM32F1xx/chconf.h Outdated Show resolved Hide resolved

zvecr force-pushed the feature/bluepill_onekey branch 2 times, most recently from 70c535b to 1e9e3c9 Compare June 30, 2019 21:14

zvecr added 4 commits June 30, 2019 22:16

Add generalised support for stm32 f103 to simplify bluepill based boards

2f0b34a

Refactor onekey/bluepill to use central STM32F103

c390e74

Add bootloader_defs for f103

cd815ab

Add guards to bootloader defs

816694f

zvecr force-pushed the feature/bluepill_onekey branch from 1e9e3c9 to 816694f Compare June 30, 2019 21:17

zvecr added 2 commits June 30, 2019 22:33

Move ld script to central location

d4ca208

Update default mcu_selection logic for USE_FPU

8e172f3

zvecr marked this pull request as ready for review June 30, 2019 23:30

Allow override of DFU_SUFFIX_ARGS on F303

e9025e0

drashna requested review from jackhumbert, algernon, fredizzimo, mechmerlin, noroadsleft and skullydazed July 1, 2019 19:50

yanfali reviewed Jul 1, 2019

View reviewed changes

yanfali approved these changes Jul 2, 2019

View reviewed changes

zvecr mentioned this pull request Jul 2, 2019

Refactor bluepill70 to current standards #6233

Closed

13 tasks

drashna requested review from a team and removed request for fredizzimo July 23, 2019 07:02

zvecr added the on hold label Oct 31, 2019

This was referenced Dec 23, 2019

Add rules.mk defaults for f103,f072,f042 #7704

Merged

Refactor stm32duino f103 keyboards to use new central board config files #7706

Merged

zvecr mentioned this pull request Jan 13, 2020

Migrate common ld scripts to common location #7887

Merged

13 tasks

zvecr closed this Feb 27, 2020

zvecr deleted the feature/bluepill_onekey branch April 28, 2020 00:15

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add generalised support for stm32 f103 to simplify bluepill based boards #5669

Add generalised support for stm32 f103 to simplify bluepill based boards #5669

zvecr commented Apr 20, 2019 •

edited

Loading

noroadsleft commented Apr 20, 2019

zvecr commented Apr 20, 2019

drashna commented Apr 28, 2019

zvecr commented Apr 28, 2019

awkannan commented Apr 29, 2019

zvecr commented May 2, 2019

zvecr commented Jun 30, 2019

yanfali left a comment •

edited

Loading

zvecr commented Jul 1, 2019

yanfali commented Jul 1, 2019

drashna commented Jul 2, 2019

yanfali left a comment •

edited

Loading

yanfali commented Jul 4, 2019

yiancar commented Jul 5, 2019

zvecr commented Jul 5, 2019 •

edited

Loading

yiancar commented Jul 5, 2019

zvecr commented Jul 5, 2019

yiancar commented Jul 5, 2019

zvecr commented Jul 5, 2019

yiancar commented Jul 5, 2019

yiancar commented Jul 5, 2019

yanfali commented Jul 5, 2019

zvecr commented Jul 5, 2019

drashna commented Jul 30, 2019

zvecr commented Jul 31, 2019

yanfali commented Aug 1, 2019

drashna commented Sep 21, 2019

zvecr commented Feb 27, 2020

Add generalised support for stm32 f103 to simplify bluepill based boards #5669

Add generalised support for stm32 f103 to simplify bluepill based boards #5669

Conversation

zvecr commented Apr 20, 2019 • edited Loading

Description

Types of Changes

Checklist

noroadsleft commented Apr 20, 2019

zvecr commented Apr 20, 2019

drashna commented Apr 28, 2019

zvecr commented Apr 28, 2019

awkannan commented Apr 29, 2019

zvecr commented May 2, 2019

zvecr commented Jun 30, 2019

yanfali left a comment • edited Loading

Choose a reason for hiding this comment

zvecr commented Jul 1, 2019

yanfali commented Jul 1, 2019

drashna commented Jul 2, 2019

yanfali left a comment • edited Loading

Choose a reason for hiding this comment

yanfali commented Jul 4, 2019

yiancar commented Jul 5, 2019

zvecr commented Jul 5, 2019 • edited Loading

yiancar commented Jul 5, 2019

zvecr commented Jul 5, 2019

yiancar commented Jul 5, 2019

zvecr commented Jul 5, 2019

yiancar commented Jul 5, 2019

yiancar commented Jul 5, 2019

yanfali commented Jul 5, 2019

zvecr commented Jul 5, 2019

drashna commented Jul 30, 2019

zvecr commented Jul 31, 2019

yanfali commented Aug 1, 2019

drashna commented Sep 21, 2019

zvecr commented Feb 27, 2020

zvecr commented Apr 20, 2019 •

edited

Loading

yanfali left a comment •

edited

Loading

yanfali left a comment •

edited

Loading

zvecr commented Jul 5, 2019 •

edited

Loading