Add support for STM32F103 (Blue Pill) #541
Conversation
There was a problem hiding this comment.
Thanks @Risca for the proposed port. This looks good so far.
- Please do get in touch with us at [email protected] to fill our Contributor Agreement form, if you haven't already, mentioning this PR.
- The hal_flash_write function is not supposed to erase sectors. Please remove all erase commands from
hal_flash_write. - Please rename the TARGET and file names to
stm32f1for consistency with other ports. - Our ports usually include also one paragraph of instructions in docs/Targets.md, and a non-regression build test in github actions, but I could also commit those on top while testing, once the above points are solved.
hal/stm32f103.c
Outdated
| return 0; | ||
| } | ||
|
|
||
| int RAMFUNCTION hal_flash_write(uint32_t address, const uint8_t *data, int len) |
There was a problem hiding this comment.
Don't worry at all about erasing the page before write. This task is performed by wolfBoot, that will always call erase before writing. If the flash memory does not support consecutive writes after erase, just add NVM_FLASH_WRITEONCE=1 to the example config, like for similar STM32 targets.
Please remove any erase commands issued in hal_flash_write.
There was a problem hiding this comment.
Ah, I see! I couldn't figure out if this was the case so I opted for the safe approach. This makes the implementation much simpler!
arch.mk
Outdated
| @@ -139,6 +139,12 @@ ifeq ($(ARCH),ARM) | |||
| ARCH_FLASH_OFFSET=0x08000000 | |||
| endif | |||
|
|
|||
| ifeq ($(TARGET),stm32f103) | |||
There was a problem hiding this comment.
I think we should rename the target (and the associated files) to stm32f1 for consistency with the other ports, to cover the entire family.
Comments in the files, referring to STM32F103, are OK, and even mentioning the BluePill in the test-app as you did is actually helpful as reference if anyone is testing on a different STM32F1.
The Blue Pill board is typically fitted with a STM32F103C8T6, but reports online seem to indicate that it sometimes can come with its bigger sibling the STM32F103C8TB as is the case with my board. This patch adds support for all low- to medium-density STM32F103 devices. All of these devices have their flash divided in 1 KB pages, up to 128 KB. The high-density and connectivity line of devices, sometimes called XL devices, use 2 KB pages and are not supported. Similar to the STM32F4 support, the code will spin up the PLL for maximum speed during init and turn it off just before booting the application. the maxium speed is 72 MHz. Signed-off-by: Patrik Dahlström <[email protected]>
The test application used during development of STM32F103 support. If booting version 1 of the software, trigger an update. If running ver. 2, all is good. Signed-off-by: Patrik Dahlström <[email protected]>
Config based on the STM32F4 ditto. Booting takes about 6 seconds and update around 15. Signed-off-by: Patrik Dahlström <[email protected]>
Signed-off-by: Patrik Dahlström <[email protected]>
I've fixed the rename and (hopefully) the build test. The rest will be a few days |
The Blue Pill board is typically fitted with a STM32F103C8T6, but
reports online seem to indicate that it sometimes can come with its
bigger sibling the STM32F103C8TB as is the case with my board.
This patch adds support for all low- to medium-density STM32F103
devices. All of these devices have their flash divided in 1 KB pages, up
to 128 KB. The high-density and connectivity line of devices, sometimes
called XL devices, use 2 KB pages and are not supported.
Similar to the STM32F4 support, the code will spin up the PLL for
maximum speed during init and turn it off just before booting the
application. the maxium speed is 72 MHz.
Booting with the example config takes around 6 seconds.
Updating takes about 15.