Tracing issues with WeAct STM32F411

Post Reply
samveen
Posts: 2
Joined: Sat Jul 11, 2020 12:54 pm

Tracing issues with WeAct STM32F411

Post by samveen »

Background
I have the WeAct BlackPill STM32F411CEU6. I don't have any meaningful prior experience with stm32 or microcontrollor/embedded systems other than a bit of playing around with an AdaFruit Feather nRF52832 with the Arduino IDE. As for tools, I have the aforementioned BlackPill, the aforemetioned `Feather nRF52832`, a Segger JLink Edu Mini with its cables, a decent beginner's soldering iron and the USB cables to connect them to my programming system, which runs Ubuntu 20.04. I don't have any other tools at all.

What I Did
- Add the https://github.com/stm32duino/Arduino_Core_STM32/ core release v1.9.0 to Arduino IDE as per instruction therein.
- First connection of the BlackPill with Arduino IDE to flash blinky did nothing.
- `dmesg` showed that the device was connected as `WeAct HID bootloader`
- Google gave me viewtopic.php?p=1640#p1640 and Blinky was up and running, using dfu-util to flash the Blinky.ino.bin created by the IDE in /tmp/arduino_build_xxx/
- More reading of the thread implied that I could use the fork of the HID_bootloader from WEACT to get seamless writing via the IDE without resorting to dfu-util

This is where I made my mistake: I used dfu-util to write the bootloader to the application area:

Code: Select all

dfu-util -a 0 -s 0x8000000 -RD hid_bootloader.bin
Why I did it: all documentation seemed to imply that the HID_bootloader code was application code, and the real application code would be loaded 16K up from 0x8000000. Even in the readme, the commands to flash the bootloader used the same address.

Why I think this is a mistake: after this, I am unable to get the board to work correctly. When not in DFU mode, the board does not register with the OS. DFU mode works perfectly, but nothing else works. I tried to re-write blinky via DFU-mode as previously, but no dice:

Code: Select all

samveen@work:/tmp/arduino_build_967$ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Cannot open DFU device 0a5c:21e6
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="3-2", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="395D367A3339"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="3-2", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="395D367A3339"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="3-2", alt=1, name="@Option Bytes  /0x1FFFC000/01*016 e", serial="395D367A3339"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="3-2", alt=0, name="@Internal Flash  /0x08000000/04*016Kg,01*064Kg,03*128Kg", serial="395D367A3339"
samveen@work:/tmp/arduino_build_967$ dfu-util -a 0 -s 0x8000000 -R -D Blink.ino.bin 
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: Cannot open DFU device 0a5c:21e6
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 11236
Download	[=========================] 100%        11236 bytes
Download done.
File downloaded successfully
dfu-util: can't detach
Resetting USB to switch back to runtime mode
Given my meager skills, and even worse variety of equipment, can I get suggestions of what I need to do to check what I can do to fix whatever issue I created?
User avatar
fpiSTM
Posts: 1738
Joined: Wed Dec 11, 2019 7:11 pm
Answers: 91
Location: Le Mans
Contact:

Re: Tracing issues with WeAct STM32F411

Post by fpiSTM »

I saw WeAct provides their boards with a derivative of the HID bootloader.
I have not this board and so never try it.
Did you enable the USB CDC support? else the upload method is not able to reset in HID BL mode.
samveen
Posts: 2
Joined: Sat Jul 11, 2020 12:54 pm

Re: Tracing issues with WeAct STM32F411

Post by samveen »

So I am back to a somewhat sane point:
- Flash the WeACT HID bootloader (binary release file from github) at address 0x8000000 (This works a bit, but not completely as documented)
- Flash Blinky at 0x8004000.

Two concerns:
- Earlier, before I messed things up, the Black Pill showed up as a USB device no matter what I did. Now the device only shows up under USB when I switch to DFU mode (Keeping boot0 pressed, reset the board)
- Why blinky doesn't work when written to 0x8000000, but works correctly when chained via the bootloader to 0x8004000.

I am definitely missing a lot of things, and hoping for some pointers on where to begin reading.

Edit 1
Following the suggestions by @fpiSTM , I changed the IDE board settings for `Upload method` to `STM32CubeProgrammer(DFU)` instead of `HIDBootloader 2.2`. That fixed the execution of blinky when written without the Bootloader.

I now understand that this is because when the upload method is set to `HID Bootloader 2.2` the build settings change the start address of the user sketch to 0x8004000, so when I write the sketch to 0x8000000, all the jump instructions have incorrect targets (offset by -0x0004000), and thus blinky fails to work (jumps from `_main` to `setup()`, `loop()` etc.).

As to showing up as a USB device, the same thing seems to happen: When the IDE thinks that the bootloader exists, it doesn't add the USB stack to the sketch, and so the board doesn't show up as a USB device when the sketch is running(as the bootloader is supposed to do the USB/Serial bits). However, changing the upload method means that the sketch has to do all the USB activities, and thus the stack is compiled into the sketch.

More experimentation and knowledge building to follow.
User avatar
fpiSTM
Posts: 1738
Joined: Wed Dec 11, 2019 7:11 pm
Answers: 91
Location: Le Mans
Contact:

Re: Tracing issues with WeAct STM32F411

Post by fpiSTM »

If you choose an upload method linked to a custom BL (HID, maple,...) then the vect tab @ will be different.
The application USB stack is not linked to the BL, if you set the USB support to CDC or HID then the application will embed it.
The only link with the BL is that with a special sequence through the USB, le board will restart in BL mode. That's all.
roboticboyer
Posts: 4
Joined: Sun Jun 07, 2020 6:29 pm

Re: Tracing issues with WeAct STM32F411

Post by roboticboyer »

Uploading the Blink Sketch the WeAct HID Bootloader has been deleted

It's possible to re-install it using this instruction https://github.com/WeActTC/MiniF4-STM32 ... -627926032
The bootloader firmware is here: https://github.com/WeActTC/MiniF4-STM32 ... r_F4x1.hex

Please note that to enter in the HID Bootloader mode is required to push the stand-alone button near the 4 pins for ST-Link
Post Reply

Return to “STM32F4 based boards”