boards: add support for bluepill board #7727

nmeum · 2017-10-12T17:36:19Z

This pull request adds support for the stm32 based bluepill board. This board is widely available at a very low cost on sites like AliExpress and others.

Initial work was done by @obgm but his RIOT fork was outdated and incomplete thus we started from scratch based on the nucleon-f103 board. However, we noticed that some peripheral configuration options were missing in the nucleon-f103 periph_conf.h header file. For instance, the general purpose timer four wasn't configured and the cs_pin for the SPI devices wasn't set. In addition to that PWM and ADC support was missing on the nucleon-f103. Compared to the nucleon-f103 we didn't configure i2c in the periph_conf.h file for the bluepill board because we couldn't test it yet, but it is very likely that the i2c configuration from the nucleon-f103 can simply be copied for this board.

All other peripherals were tested using the tests available in tests/. We are also planning to expand support for this board in the future. Apart from i2c we would also like to add support for CAN available on the device.

This was a group effort involving Alexander Kurth, Tristan Bruns, Christian Manal and myself.

bergzand · 2017-10-12T18:10:42Z

Is there a difference between this board and the already existing maple mini board? As far as I can see, they look (to the eye) identical and they have the same cpu.

nmeum · 2017-10-12T18:56:43Z

It is as similar to the maple-mini as it is to the nucleo-f130. The definitions in board.h differ and the defintions in periph_conf.h are only similar because the boards use the same chip.

It would probably be a good idea to add an stm31f103_common folder to boards which behaves similar to the iotlab_common folder.

bergzand · 2017-10-12T19:05:07Z

I was afraid that there would be some duplicate work, but good that it is not the case here.

smlng · 2017-10-16T16:26:39Z

Hi, I tested with my bluepill board, which has a stm32f103c8t6 MCU, not stm32f103cb as configured here. While tests/led is working, I cannot connect to terminal (likely some UART issue), i.e., BOARD=bluepill make term does not work, but if I try BOARD=samr21-xpro make term it runs pyterm but no output is visible.

With #7735 it works as expected ...

kurth1 · 2017-10-16T17:05:01Z

The three UART port are in a different order in this PR then in #7735, which means the pins of the UART used for stdout are different. This might explain your issue.

The hardware we used for testing also uses a STM32F103C8T6, the CPU definition uses a STM32F103CBT6 because we are pretty sure that they have 128 KiB Flash anyway, as mentioned here. Since this is not yet 100% conclusive, it would be awesome If people with this hardware could test this.

smlng · 2017-10-16T18:32:16Z

@kurth1 thanks for the infos!

Regarding the UART: yes saw that, too - still I think its better to use UART2 (as in #7735) for RIOTs term/shell connection because UART1 lies on the same pins as I2C1, see here.

Regarding the flash size, I don't know wouldn't it be safer to use the lower variant as default until further verification. I guess with those cheap boards it may depend on the production line which it will be, and could lead to some nasty to debug errors, if one has a device with only 64KB flash.

pyropeter · 2017-10-16T20:31:19Z

I don't really know why make term should work. The bluepill has no internal usb-to-serial-converter. We can make no assumptions at all about how the user chooses to connect the serial ports to a computer.

smlng · 2017-10-17T07:40:25Z

@pyropeter you're right, but that's true for many boards.

Still it would be good to have a sensible default, which also allows other periphs to run by default as well. That's why I would recommend to set UART2 as the default for RIOTs primary shell-UART. UART1 and 3 collide with I2C, though I know UART2 collides with some ADC pins, but there are 8 of them so we can manage to loose 2 of them for UART, right?

jnohlgard · 2017-10-17T09:40:16Z

I suggest you keep the ordering of the UART modules to match the chip order, and instead define UART_STDIO_DEV in board.h. See boards/mulle/include/board.h for an example.

nmeum · 2017-10-17T12:02:40Z

@smlng We adjusted the CPU_MODEL accordingly and defined the UART_STDIO_DEV macro as suggested by @gebart. We also included and configured $(RIOTBOARD)/Makefile.include.serial in Makefile.include.

nmeum · 2017-10-17T13:29:14Z

We also copied and tested the saul gpio configuration and changes made to the Makefiles in tests/ and examples/ from #7735 now.

smlng · 2017-10-19T19:46:02Z

@nmeum nice work and thanks for adapting to suggestions, I'll close #7735.

smlng · 2017-10-19T19:58:55Z

Before merge I'd like to verify that SPI is working with the given configuration, I'll try to test within the next days.

Further, I've some concerns regarding the board name, it might be worth considering to rename it into stm32bluepill (or even stm32f1bluepill) so its more obvious to which family it belongs - its just a thought, any opinions?

nmeum · 2017-10-20T19:36:58Z

I don't have a strong opinion on this, the board name is just a string after all. However, the other boards in boards/ using an stm32 are not prefixed with stm32 either. Therefore I would prefer not renaming the board.

bergzand · 2017-10-20T19:48:53Z

I'm against rename the board to something with stm32, to me that would make it appear as if there are multiple versions of the bluepill board.

Would a symlink from boards/stm32f103c8 to boards/bluepill work here? I don't know if RIOT-OS has an opinion on using symlinks in the repository.

jnohlgard · 2017-10-20T20:12:58Z

We used to have some symlinks in the repo before, but it causes issues for users on windows and using some file systems so we replaced them. I suggest just adding some more information in the board's doxygen page regarding names and what else might be relevant.

bergzand · 2017-10-20T20:24:06Z

@gebart I agree with adding information to the doxygen. I can imagine symlinks causing weird issues on different platforms :(

nmeum · 2017-10-20T21:24:47Z

We are intending to also write a wiki page about this board. Wouldn't it be better to place this information in the wiki?

jnohlgard · 2017-10-23T07:30:24Z

@nmeum sorry for the confusion. This information is perfect for the wiki, but it is also good to have some kind of references for alternate names directly in the source tree as well (Doxygen).

You may put the information wherever you think is best (or both), as long as there is some text describing that this board has several different names across the web, to make it more likely to find the correct page when someone is searching for this board.

There's an ongoing discussion regarding where to put information about the supported platforms (wiki vs. Doxygen). I favor Doxygen because that is where I tend to look first and I think it is easier to keep up to date when things are added or modified, but others favor the wiki because it may be more familiar.

smlng

verified by testing, basic board supports works.

smlng · 2017-10-27T08:28:16Z

fixes #6967

nmeum · 2017-10-27T13:42:52Z

We just added a few comments regarding the flash size to the doxygen documentation as suggest by @gebart. Is there anything else we can do to get this merged?

smlng

minor nits

smlng · 2017-10-27T13:55:34Z

boards/bluepill/include/board.h

+#endif
+
+/**
+ * @brief   LED pin definitions and handlers


use @name for doxygen grouping, as done below for xtimer config

smlng · 2017-10-27T13:56:33Z

boards/bluepill/include/board.h

+ * @defgroup    boards_bluepill Bluepill board
+ * @ingroup     boards
+ * @brief       Support for the stm32f103c8 based bluepill board.
+ * @details     This board can be bought very cheaply on sides like eBay


add empty line and omit @details - IMHO its not needed when separated from @brief by an empty line

smlng · 2017-10-27T13:59:32Z

you may squash fixes directly.

nmeum · 2017-10-27T14:07:24Z

@smlng Done!

smlng · 2017-10-27T14:23:24Z

I'm happy and will test later at home, where I have the board ready for testing. If nobody objects until then I tend to merge this. Any further additions etc. can be done in followup PRs.

smlng · 2017-10-27T14:23:45Z

Nice work btw.!!!

smlng · 2017-10-27T18:32:36Z

ACK & GO!

nmeum · 2017-11-07T13:01:24Z

We are intending to also write a wiki page about this board. Wouldn't it be better to place this information in the wiki?

We just published a wiki page for this board: https://github.com/RIOT-OS/RIOT/wiki/Board:-Bluepill we are intending to improve this because we still don't know how to force OpenOCD to use 128 KB instead of 64 KB flash on this board. In case somebody knows how to do that let us know …

kYc0o · 2017-11-07T13:12:37Z

Is OpenOCD throwing an error when you try to flash it? Or it's at linking? If linking is the problem #7799 can solve it.

However, OpenOCD just gets the size of the ROM by reading it from the chip (through the model), thus even if the mcu has actually more ROM OpenOCD cannot "override" the configuration for the given model.

nmeum · 2017-11-07T13:19:23Z

Is OpenOCD throwing an error when you try to flash it? Or it's at linking? If linking is the problem #7799 can solve it.

OpenOCD doesn't throw an error at all. It allows me to flash the binary but the program doesn't work accordingly afterwards.

However, OpenOCD just gets the size of the ROM by reading it from the chip (through the model), thus even if the mcu has actually more ROM OpenOCD cannot "override" the configuration for the given model.

I only looked at this very briefly but there seems to be an OpenOCD flash bank commando: http://www.openocd.org/doc/html/Flash-Commands.html#Flash-Commands which I believe might allow us to override the default flash bank size. Or am I wrong about this?

kYc0o · 2017-11-15T18:07:23Z

Taking more closely a look, this seems to be a "printing" error, since "8" and "B" look quite similar.

Thus, can we assume that bluepill has a stm32f103cb in all cases?

smlng · 2017-11-15T18:33:28Z

can we assume that bluepill has a stm32f103cb in all cases

no we cannot (and shouldn't). We lately bought 60 blueppills and for only 3 (that is 5%) openocd reported 128KB flash size the rest was 64KB. Though they might have 128KB too in theory, I wouldn't recommend to count on that in all cases.

pyropeter · 2017-11-16T00:03:58Z

We lately bought 60 blueppills and for only 3 (that is 5%) openocd reported 128KB flash size the rest was 64KB.

Do those three chips have a stm32f103cb marking? I'm quite curious because from the inside the only way to tell the two chips apart is to read the flash size register, which is what openocd does. (One could also try to detect the flash size by writing and reading the extended flash addresses.)

I only looked at this very briefly but there seems to be an OpenOCD flash bank commando: http://www.openocd.org/doc/html/Flash-Commands.html#Flash-Commands which I believe might allow us to override the default flash bank size. Or am I wrong about this?

@nmeum, after looking at the code, I'm sure this will work. I'm still not sure if the extra flash should be used, though.

smlng · 2017-11-16T07:37:53Z

@pyropeter for me all 60 bluebills we bought are marked as stm32f103c8t6 but for 3 or 4 of them openocd reported a flash size of 128KB, all other are reported to have 64KB.

smlng · 2017-11-16T07:39:04Z

i.e., also those with 128KB are labeled stm32f103c8t6

kYc0o mentioned this pull request Oct 13, 2017

[WIP] Factorise stm32 and sam0 linker scripts #7729

Closed

50 tasks

nmeum mentioned this pull request Oct 13, 2017

stm32: approach for common peripheral definitions #7734

Closed

jnohlgard changed the title ~~add support for bluepill board~~ boards: add support for bluepill board Oct 14, 2017

pyropeter mentioned this pull request Oct 14, 2017

Board: initial support for the STM32F103C8T6 #7735

Closed

smlng added Area: boards Area: Board ports Type: new feature The issue requests / The PR implemements a new feature for RIOT labels Oct 16, 2017

kurth1 force-pushed the bluepill-rebased branch from 49f1507 to ae8545b Compare October 17, 2017 11:57

nmeum force-pushed the bluepill-rebased branch from a2f5a97 to 50bd71c Compare October 17, 2017 13:01

nmeum force-pushed the bluepill-rebased branch from 50bd71c to 05ab6ca Compare October 17, 2017 13:30

smlng self-assigned this Oct 19, 2017

smlng added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Oct 19, 2017

smlng mentioned this pull request Oct 20, 2017

Questions regarding support for STM32F103C8 #6967

Closed

smlng approved these changes Oct 27, 2017

View reviewed changes

aabadie mentioned this pull request Oct 27, 2017

readme: bump supported boards count #7885

Merged

nmeum force-pushed the bluepill-rebased branch from 05ab6ca to 7e391c4 Compare October 27, 2017 13:41

smlng suggested changes Oct 27, 2017

View reviewed changes

add support for bluepill board

9b3714b

nmeum force-pushed the bluepill-rebased branch from 7e391c4 to 9b3714b Compare October 27, 2017 14:06

smlng approved these changes Oct 27, 2017

View reviewed changes

smlng merged commit 2e0917c into RIOT-OS:master Oct 27, 2017

boards: add support for bluepill board #7727

boards: add support for bluepill board #7727

Conversation

nmeum commented Oct 12, 2017 • edited Loading

bergzand commented Oct 12, 2017

nmeum commented Oct 12, 2017

bergzand commented Oct 12, 2017

smlng commented Oct 16, 2017

kurth1 commented Oct 16, 2017

smlng commented Oct 16, 2017

pyropeter commented Oct 16, 2017

smlng commented Oct 17, 2017

jnohlgard commented Oct 17, 2017

nmeum commented Oct 17, 2017 • edited Loading

nmeum commented Oct 17, 2017

smlng commented Oct 19, 2017

smlng commented Oct 19, 2017

nmeum commented Oct 20, 2017

bergzand commented Oct 20, 2017

jnohlgard commented Oct 20, 2017

bergzand commented Oct 20, 2017

nmeum commented Oct 20, 2017

jnohlgard commented Oct 23, 2017

smlng left a comment

Choose a reason for hiding this comment

smlng commented Oct 27, 2017

nmeum commented Oct 27, 2017

smlng left a comment

Choose a reason for hiding this comment

smlng Oct 27, 2017

Choose a reason for hiding this comment

smlng Oct 27, 2017

Choose a reason for hiding this comment

smlng commented Oct 27, 2017

nmeum commented Oct 27, 2017

smlng commented Oct 27, 2017

smlng commented Oct 27, 2017

smlng commented Oct 27, 2017

nmeum commented Nov 7, 2017 • edited Loading

kYc0o commented Nov 7, 2017

nmeum commented Nov 7, 2017

kYc0o commented Nov 15, 2017

smlng commented Nov 15, 2017

pyropeter commented Nov 16, 2017

smlng commented Nov 16, 2017

smlng commented Nov 16, 2017

nmeum commented Oct 12, 2017 •

edited

Loading

nmeum commented Oct 17, 2017 •

edited

Loading

nmeum commented Nov 7, 2017 •

edited

Loading