Added a new flashing parameter for generic cheap St-link and bluepill(-128kib) boards.

[Vinggui]

Contribution description

It is now possible to use a new flashing parameter BOOTLOADER=stm32duino for those cheap generic bluepill(-128kib) boards (stm32F1x) while keeping backward compatibility.

It fixes the 'make flash' using clone stlink-v2 (use SRST=none). It also fixes flashing when using "PROGRAMMER=dfu-util", if your device already has the bootloader (stm32duino) installed somehow (like using Serial connection).

This PR changes:

• RIOT/boards/common/blxxxpill

Bugs fixed when flashing generic STM32 bluepill boards with stlink-v2

• Openocd does not recognize the chip ID:

### Flashing Target ###
Open On-Chip Debugger 0.10.0+dev-01157-gd6541a81-dirty (2020-04-02-13:58)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_assert_srst

Info : clock speed 1000 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.164062
Warn : UNEXPECTED idcode: 0x2ba01477
Error: expected 1 of 1: 0x1ba01477

Solution: Added new .cfg for generic board with
set CPUTAPID 0x2ba01477

• Openocd cannot halt the device:

### Flashing Target ###
Open On-Chip Debugger 0.10.0+dev-01157-gd6541a81-dirty (2020-04-02-13:58)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_assert_srst

Info : clock speed 1000 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.151562
Info : STM32F103C8Tx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 35283 for gdb connections
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* STM32F103C8Tx.cpu  hla_target little STM32F103C8Tx.cpu  running

Error: timed out while waiting for target halted
TARGET: STM32F103C8Tx.cpu - Not halted
/home/vini/temp-projects/RIOT/tests/leds/../../Makefile.include:667: recipe for target 'flash' failed
make: *** [flash] Error 1

Solution: Changed reset_config line in the new .cfg for generic board
from
reset_config srst_only srst_nogate connect_assert_srst
to
reset_config none srst_nogate connect_assert_srst

Bugs fixed when flashing generic STM32 bluepill boards with stm32duino bootloader

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
dfu-util: Could not read name, sscanf returned 0
dfu-util: Failed to parse memory layout
/home/user/RIOT/tests/leds/../../Makefile.include:667: recipe for target 'flash' failed
make: *** [flash] Error 74

Solution: Changed blxxxpil makefile for generic board

FFLAGS_OPTS ?= -R
FFLAGS ?= --device $(DFU_USB_ID) \
        --alt $(DFU_ALT) \
        --download $(FLASHFILE) \
        $(FFLAGS_OPTS)

Testing procedure

If you are trying to flash for it, just add "BOOTLOADER=stm32duino" or "SRST=none" before "make flash".
BOARD=bluepill SRST=none make clean all flash
BOARD=bluepill PROGRAMMER=dfu-util BOOTLOADER=stm32duino make clean all flash

In case of dfu-util programmer, you need to synchronize pushing the reset button before flashing it.

Issues/PRs references

Maybe solves issue #11030

[benpicco]

Thank you for the patch!
But it looks like some unrelated changes have crept in.
Please remove those.

[Vinggui]

I have no idea how my original commit had files that I didn`t change if I cloned this repo and then added my modification, just for the fork!
Well, I removed those files now. Let's see if it is accepted.
thanks @benpicco

[benpicco]

Thank you much better now :)
Just a question, why add a new config instead of improving the existing configuration?
Are there some boards that only work with the old / new config?

[Vinggui]

@benpicco I am recently working with these stm32fx "bluepill" boards, and I read that there are clone versions (very cheap) and the original ones. Besides, the blackpill board also shares "common/blxxxpil" folder and its files.

So, I believe that who implemented these configurations and who is currently using RiotOS with these boards probably have everything working well. Changing some configuration here could slightly change their system.

Meanwhile, adding a new config for these generic boards will keep the old behavior for original boards while adding portability. Configuration differences will impact only new projects using the new clone boards.

I tried to optimize code to my best and avoid creating new files, but by my observation, it would just make code harder to read and little improvement to it.

Thank you!

[maribu]

Openocd cannot halt the device

Please read the documentation regarding flashing. It seems that you didn't connect the SRST signal.

The change to none in the reset config means that the programmer is unable to reset the board externally. So it needs to connect via SWD first to trigger the reset. However, the STM32F103 cannot be connected to during lowest power state, e.g. after a panic(). A consensus has been reached that the effort of connecting one jumper wire more for the reset signal is a good trade for a reliable mean to flash the boards.

Btw: Did you try flashing with the lasted OpenOCD (that is compiling it from source)? Maybe a separate config is no longer needed when a new release of OpenOCD is published?

[Vinggui]

@maribu Thanks for your reply.
First, I have searched a lot before finding this "none" reset option. Indeed, you are right. I guess I could change the parameter added to indicate reset by "none" or "SRST". Connecting a reset jumper is a simple "compromise", but I think this information should be in the readme of this board in RiotOS too.

I have the lastest compiled Openocd version. For me, it did not automatically work with a cloned version of bluepill. The CPUTAPID is not correct for it, the clone has 0x2ba01477.

#jtag scan chain
if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   if { [using_jtag] } {
      # See STM Document RM0008 Section 26.6.3
      set _CPUTAPID 0x3ba00477
   } {
      # this is the SW-DP tap id not the jtag tap id
      set _CPUTAPID 0x1ba01477
   }
}

Also, I think this short answer you gave us over this topic will already help many in the community, connecting this "error" to the solution.

[maribu]

but I think this information should be in the readme of this board in RiotOS too.

The documentation page of the Bluepill (128 KiB version) contains only a single sentence, referring to the common documentation of the Bluepill / Blackpill boards. (Same for the other Bl*pill flavors.) And that is where the flashing info is. To me, this counts as properly documented 😉

I have the latest compiled Openocd version. For me, it did not automatically work with a cloned version of bluepill.

That is a pitty. Citing the OpenOCD doc on -expected-id (emphasizes added by me):

-expected-id NUMBER
A non-zero number represents a 32-bit IDCODE which you expect to find when the scan chain is examined. These codes are not required by all JTAG devices. Repeat the option as many times as required if more than one ID code could appear (for example, multiple versions).

So, it would be possible to just list both IDs here and it would work for both flavors, without having the user to worry which chip the bluepill contains. From the user experience point of view, that would be the best solution. For now, this would require having our own stm32f1x.cfg in the RIOT repository until both IDs are supported upstream. It is 89 lines of code; so not that much of a hazzle. Another advantage of this would be that the 128 KiB versions of the boards could be used with the current stable version of OpenOCD.

So: I'd say this would be the route to go. @Vinggui, @benpicco: What do you think?

[Vinggui]

I have been playing around with options the whole day and using my St-link v2 (clone version), and I still haven't been able to flash my stm32fx using the srst_only parameter. I have read some topics saying that maybe Clone St-links do not have their RST pin working.

This leads me to think that other people might be having the same issue. So, making an option for generic boards/programmers could make their life easier.

@maribu I really appreciate your input, please keep helping me finding common ground and a better solution. However, I don't think that having a full version of this openocd config stm32f1x.cfg is the way to go since future updates from their side could be missed. We just need some parameters in addition to the default one.

So, it would be possible to just list both IDs here and it would work for both flavors, without having the user to worry which chip the bluepill contains.

We could do that in our config and keep the append source [find target/stm32f1x.cfg] to the default config.

If you agree, I can work on it right now. Meanwhile I'm trying to make my St-link reset with the pin....

[maribu]

So, it would be possible to just list both IDs here and it would work for both flavors, without having the user to worry which chip the bluepill contains.

We could do that in our config and keep the append source [find target/stm32f1x.cfg] to the default config.

Maybe setting CPUTAPID to 0x1ba01477 -expected-id 0x2ba01477 could work. But I don't see a clean way to do this.

I have read some topics saying that maybe Clone St-links do not have their RST pin working.

I can confirm this. In the worst case, you could just manually press the reset button. Keep it pressed until OpenOCD starts, then release the button.

This issue is however completely unrelated to whether your bluepill has a genuine STM32F103 or a clone MCU; it is only related to your debugger. A global solution like make NO_SRST=1 flash that would work for every board using OpenOCD (or at least those without integrated debugger) would however be a nice addition for users without a proper debugger.

Btw: If you have a cheap ST-Link clone, you can convert it to a black magic probe. RIOT supports the Black Magic Probe for many boards by passing the PROGRAMMER variable, e.g. make PROGRAMMER=bmp flash. Beware that every cheap ST-Link clone as a different pinout regarding both the headers as well as the debug connectors for programming. I recommend to use a good multimeter to figure out the pinout of your clone. As BMP is open source, you can change the pin mapping in a header file to match your hardware at hand. In my personal experience, BMP is the most robust and reliable programmer for ARM targets. And that would also solve the reset issue, provided that the reset pin on the clone is at least connected to any pin at all ;-)

[Vinggui]

First, thank you for sharing this bmp info. I'll look into it.

Maybe setting CPUTAPID to 0x1ba01477 -expected-id 0x2ba01477 could work. But I don't see a clean way to do this.

I think that -expected-id is already being used with the exact tag we set (line 46)
swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
On the other hand...

-expected-id NUMBER
A non-zero number represents a 32-bit IDCODE which you expect to find when the scan chain is examined. These codes are not required by all JTAG devices. Repeat the option as many times as required if more than one ID code could appear (for example, multiple versions). Specify number as zero to suppress warnings about IDCODE values that were found but not included in the list.

so copying the entire cfg could indeed work.

I found some better ways to work this around, but we needed more flexibility from the openocd.sh. Something like adding and EXTRA_CONFIG_COMMAND in here

# flash device
    sh -c "${OPENOCD} \
            ${OPENOCD_ADAPTER_INIT} \
     ---->  ${EXTRA_CONFIG_COMMAND} \
            -f '${OPENOCD_CONFIG}' \
            ${OPENOCD_EXTRA_INIT} \
            ${OPENOCD_EXTRA_RESET_INIT} \
            -c 'tcl_port 0' \
            -c 'telnet_port 0' \
            -c 'gdb_port 0' \
            -c 'init' \
            -c 'targets' \
            -c 'reset halt' \
            ${OPENOCD_PRE_FLASH_CMDS} \
            -c 'flash write_image erase \"${IMAGE_FILE}\" ${IMAGE_OFFSET} ${IMAGE_TYPE}' \
            ${OPENOCD_PRE_VERIFY_CMDS} \
            -c 'verify_image \"${IMAGE_FILE}\" ${IMAGE_OFFSET}' \
            -c 'reset run' \
            -c 'shutdown'" &&
    echo 'Done flashing'

The way it is now, it requires many duplicated versions of .cfg files for each case. I think it's bad, but its the "only" way. I could do some work around this, but it would not be elegant.

[Vinggui]

Ok...
I believe I fixed it. But I don't know if I create another pull request or change the files in this on.

First

I fixed the target/stm32f1x.cfg in openocd project (also available in my personal fork). So I recommend using this mod until the PR in openocd get merged (if it does...)

#jtag scan chain
if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   if { [using_jtag] } {
      # See STM Document RM0008 Section 26.6.3
      set _CPUTAPID 0x3ba00477
   } {
      # this is the SW-DP tap id not the jtag tap id
      set _CPUTAPID {0x1ba01477 0x2ba01477}
   }
}

# Expand CPUTAPID parameters
set _EXPECTED_IDS {}
foreach id $_CPUTAPID {
   lappend _EXPECTED_IDS -expected-id $id
}

swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf {*}$_EXPECTED_IDS

Second

If you have a clone St-link debugger without the reset function, you can now make SRST=<option> as:
BOARD=bluepill SRST=none make clean all flash

Third

I renamed the GENERIC=1 option to BOOTLOADER=stm32duino, since this is still necessary if you are using that bootloader for this project.

[maribu]

I have some minor remarks inline, but in general t his looks good to me. I'm not sure about the bootloader; I have the feeling that this might not be the best option to get DFU updates. I think @benpicco has more expertise on this.

If there is indeed a better option for DFU updates, I think it would be better to just recommend using that bootloader instead.

[maribu]

This should be documented in boards/common/blxxxpill/doc.txt. (@benpicco: The other dfu bootloader doc is btw also missing. Care to add this?)

Also: The README of the stm32duino bootloader says this:

Also Note: Use GCC 4.8 (not 4.9 or newer, as those versions have more aggressive optimisation which cause hardware registers to be read incorrectly and consequently the bootloader does not work)

This is a highly significant indicator of code quality problems of the bootloader. (If your code breaks by updating GCC, in 999 out of 1000 cases the problem is your code, not GCC. I bet they forgot to add the volatile qualifier for accessing memory mapped I/O or similar.) Maybe it is just better to use a different bootloader instead?

[Vinggui]

I think you did put a very pertinent question.

I got to know Riot a few years ago, but haven`t worked on it so far. Now I got some cheap boards (bluepills) to experience this system as an alternative or my projects. In my short experience working on STM32, I went through a lot of options to flash it, and one of the most cited/documented in the community was this stm32duino bootloarder.

During my attempts to flash using dfu provided in Arduino and Riot, I found this difference that made it actually possible to use their bootloader into Riot. With Riot`s default configuration for dfu, it did not work at all.

So, in general, I think you made a very good point, @benpicco indeed could give us some insight, but I think that leaving this BOOTLOADER=stm32duino option might be very useful for newcomers like me, especially if they have lesser knowledge about these things.

[benpicco]

Sorry I've bee busy the last couple of days - I'm not sure why you assume I have much knowledge about DFU bootloaders though 😆
You added the config for dfu-util(#12697), I just happened to use it. So I'm also not sure what doc you mean.

If using upload-reset makes flashing easier, why not always use it and download that tool on-demand? I wouldn't download the binary though, just the source and compile it like it's done with other tools.

upload-reset would then be added to FLASHDEPS.

[maribu]

Is the RESET_STM variable anywhere referenced? It seems to neither be referenced in code introduced by this PR nor by existing code in RIOT. Thus, I don't see how this should have an impact.

[Vinggui]

    # Flashing may be easier when uncommenting the "RESET_STM" line and
    # using the binary "upload-reset" from rogerclarkmelbourne/Arduino_STM32.
    # github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/tools/linux/upload-reset
    # RESET_STM := $(shell $(RIOTBOARD)/common/blxxxpill/bin/upload-reset /dev/ttyACM0 750)

RESET_STM is commented as one possible solution/improvement for someone trying stm32duino bootloader.

[Vinggui]

Oh ok. I did not see this PREFLASHER option before. Nice!
Ok, it could be changed to that, IF your first USB reset does not work instead since we already have that.
But in any case, this is only useful if USB is on, which is not yet. I dont know if its worth changing this right now. I gotta check the USB first.

[benpicco]

Yea so better remove it for now, maybe add a comment that upload-reset can be used in the future.

[Vinggui]

I still think that a comment would still be helpful for some people and still not affect code anyhow. But, in this case, it's your call.

[benpicco]

A comment that upload-reset /dev/ttyACM0 750 should be used as PREFLASHER once we have USB support for stm32f1 is good, but let's not get people to think this implicit reset at Makefile evaluation would be a good idea 😉

[Vinggui]

Doing it now. But, important to remember that the bootloader has USB support, and that is why the reset command can improve this procedure.
So I'm going to test this PREFLASHER option now.

[maribu]

Btw: How does this affect flashing?

[Vinggui]

That's is why I did not incorporate this code into the commit, just mentioned the possibility.
Indeed, there are some caveats:

1- Arduino's structure uses USB for its stdio (which should be one of my priorities soon). Hence, this RESET_STM works great (if CPU is not in delay()). But in Riot, USB is not active after bootloading, so the reset won't kick in after that, reset must be pressed manually.

2- During the flash of the Riot's default dfu configuration, it does not wait the device to be reset, then it makes very hard to synchronize both actions manually. With this RESET_STM, stm32duino receives a command to wait for flash and makes dfu synchronization easier (that was my impression). So I decided to leave this suggestion commented.

I wouldn't mind removing this, but what is the problem of some more information/help?

[benpicco]

btw.: this seems very similar to what is done on sam0 with the Arduino bootloader (#12304), so the RIOT USB stack already has a baudrate hack in place to trigger a bootloader reset.

Unfortunately the USB peripheral is not the same across all stm32, so currently stm32f1 has no USB support in RIOT.

[Vinggui]

In any case, this reset is not absolutely necessary, and it may not always work, because of USB peripheral not available.
I wonder how easy would it be to port the code from Arduino, they use USB as STDIO.

[benpicco]

You can use USB as STDIO too in RIOT, just not on stm32f1 (yet) - you'd have to implement/adopt stm32_common/periph/usbdev.c.

On stm32f4 (e.g. #12778) stdio over USB works just fine.

[Vinggui]

I'm sorry, I meant that I agree with you.
My point is that in Arduino stm32f1 is already working with USB as STDIO too, so maybe just observing their code and adapting into RIOT could be possible/faster.

[benpicco]

I don't think there is any technical reason for why it's not done for stm32f1 yet - it's just that nobody has done it yet/is actively working on it.

If you want to work on this, that would be great!

[Vinggui]

I should. I would like to use it too, but first I wanna get this one done.

[benpicco]

Sorry that we dropped this here.
I think this should be mostly good, just two things:

• change the commit message to something like boards/blxxxpill: add support for stm32duino bootloader
• drop that RESET_STM line - we have better ways to trigger a bootloader reset than this implicit Make magic once USB support is there.

[Vinggui]

@benpicco Done.