search

blackmagic-debug / blackmagic

In application debugger for ARM Cortex microcontrollers.
GNU General Public License v3.0
3.27k stars 774 forks source link

blackpillv2: unresponsive board when uploading locally built .bin file #1454

Closed lenvm closed 1 year ago

lenvm commented 1 year ago

Introduction

Flashing the blackpillv2 with a blackmagic-blackpillv2.bin file built locally using commit 32543bb (v1.9.0) leads to a non-functional board. It seems this issue could be specific to my case.

Methodology

The file is created using

make all_platfroms

The file size is 149232 bytes. A file with the same size can be created using make PROBE_HOST=blackpillv2.

I have first uploaded the .bin file using dfu-util. Dfu-util successfully uploads 149232 bytes. However, it leads to a non-responsive board, which does not show up as a device when connected via USB to the computer. Second I tried uploading the .bin file with st-flash. This also uploads successfully, but leads to an non-responsive board as well. Please see the sections below for the commands I used and the full responses.

The only way I get the board working again is to upload the blackmagic-blackpillv2.bin file from blackmagic-firmware.zip, hosted on koendv's GitHub, using st-flash. After uploading the board is responsive again. Next I can update the board again using dfu-util. In that case dfu-util reports uploading 121336 bytes.

Problem

Therefore it seems that there is an issue with the the .bin file when I build it locally. Especially it is strange that the size of the .bin file is 149232 bytes rather than 121336 bytes. I would be glad if you can help me find out why the board may not function with the locally built .bin file, and why the locally built .bin file is larger than the one obtained from koendv's GitHub.

I am using:

Commands

dfu-util

dfu-util -a 0 --dfuse-address 0x8000000:leave -R -D blackmagic-blackpillv2.bin

Returns:

dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 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: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 1d50:6018
Run-Time device DFU version 011a
Claiming USB DFU (Run-Time) Interface...
Setting Alternate Interface zero...
Determining device status...
DFU state(0) = appIDLE, status(0) = No error condition is present
Device really in Run-Time Mode, send DFU detach request...
Device will detach and reattach...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading element to address = 0x08000000, size = 149232
Erase           [=========================] 100%       149232 bytes
Erase    done.
Download        [=========================] 100%       149232 bytes
Download done.
File downloaded successfully
Submitting leave request...
Transitioning to dfuMANIFEST state
dfu-util: can't detach
Resetting USB to switch back to Run-Time mode

st-flash

 st-flash --flash=512k write blackmagic-blackpillv2.bin 0x8000000

Returns:

st-flash 1.7.0
NFO common.c: F4xx (low power): 64 KiB SRAM, 128 KiB flash in at least 16 KiB pages.
Forcing flash size: --flash=0x00080000
file blackmagic-blackpillv2.bin md5 checksum: 9d634a1f44d25f3384ce63e0bc4a78c4, stlink checksum: 0x00b477eb
INFO common.c: Attempting to write 121336 (0x1d9f8) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000 INFO common.c: Flash page at addr: 0x08000000 erased
EraseFlash - Sector:0x1 Size:0x4000 INFO common.c: Flash page at addr: 0x08004000 erased
EraseFlash - Sector:0x2 Size:0x4000 INFO common.c: Flash page at addr: 0x08008000 erased
EraseFlash - Sector:0x3 Size:0x4000 INFO common.c: Flash page at addr: 0x0800c000 erased
EraseFlash - Sector:0x4 Size:0x10000 INFO common.c: Flash page at addr: 0x08010000 erased
INFO common.c: Finished erasing 5 pages of 65536 (0x10000) bytes
INFO common.c: Starting Flash write for F2/F4/F7/L4
INFO flash_loader.c: Successfully loaded flash loader in sram
INFO flash_loader.c: Clear DFSR
INFO flash_loader.c: Clear CFSR
INFO flash_loader.c: Clear HFSR
INFO common.c: enabling 32-bit flash writes
INFO common.c: Starting verification of write complete
INFO common.c: Flash written and verified! jolly good!
lenvm commented 1 year ago

Problem 1: Unresponsive board [solved]

I have been able to get the code to work on the board, after changing the memory sizes using the following patch:

-   rom (rx) : ORIGIN = 0x08000000, LENGTH = 512K
-   ram (rwx) : ORIGIN = 0x20000000, LENGTH = 96K
+   rom (rx) : ORIGIN = 0x08000000, LENGTH = 256K
+   ram (rwx) : ORIGIN = 0x20000000, LENGTH = 64K

This is taken from koendv's blackmagic.patch.

The board I used is a WeAct Studio Black Pill V1.2, which has a STM32F401CCU6 microcontroller with only 256kB of flash. The flash size being defined as 512kB rather than the actual flash size of 256kB caused the unresponsive board.

Therefore the issue reported is not really a bug in the code.

Problem 2: The file size is different when building locally on macOS [solved]

The file size flashed to the board is now 149236 bytes. This is much larger than the size of the blackmagic-blackpillv2.bin file obtained from koendv's GitHub, built on linux (121336 bytes).

It would be great if someone could help me debug why this is happening.

esden commented 1 year ago

@lenvm a common issue with resulting binary size is caused by using the wrong cross compiler. The known good cross compiler is the one provided by ARM. Often, distribution supplied cross compilers will build a much larger binary than the ARM toolchain.

lenvm commented 1 year ago

Hi @esden, thank you for your response!

I’m actually using Arm GNU Toolchain 12.2.rel1, specifically from the section: macOS (Apple Silicon) hosted cross toolchains AArch32 bare-metal target (arm-none-eabi)

Is there anything else I shall do to get the ARM toolchain to compile the small-size binary?

dragonmux commented 1 year ago

Ah, you're using a Blackpill v1.2 with the Blackpill v2 platform - this is unsupported. Because there's more than just a Flash size difference between those two microcontrollers, they need to be separate platforms.

If you want to dupe the blackpillv2 platform as blackpillv1, and properly go through fixing the various settings, pin assignments, etc, for Blackpill v1, we're happy to take that as a PR with the understanding that when the BMD v2.0 dev cycle is begun, we will reduce it down to a blackpill platform if possible sanely and expose the different Blackpill variants in the build system configuration menu system that will be added.

See #1048, and #453 for more details on the prior conversations about this.

lenvm commented 1 year ago

Hi @dragonmux, thanks for your inputs!

Can you elaborate on the other differences between the Black Pill V1.2 and V2.0? I have only found differences in rom and ram, and some of the V2.0 (STM32F11) pins not being 5V tolerant. The pinout is the same as far as I can see from Zephyr Project.

453 focuses on the Black Pill with STM32F1 microcontroller. I would keep this out of scope, and focus on the STM32F4 boards.

Reading the thread in #1048, if only the rom and ram are different, I was thinking it could make sense to change the platform from blackpillv2 to blackpill-f4. This would allow the code to support all blackpill-f4 boards (V1.2, V2.0 and V3.0). Ram for all these boards is more than sufficient to flash the black magic code, so I believe no one would suffer from having one platform to support all boards. This would have the benefit, over having separate blackpillv1 and blackpillv2 and potentially blackpillv3 platforms, that changes (features/fixes) done for one board don’t need to be repeated for other boards as well.

Additionally, when the BMD v2.0 development cycle starts, one could start from one blackpill-f4 platform, and expose the differences in rom and ram in the configuration menu you mentioned. This prevents having to merge and fix conflicts between the (unintended) differences of blackpillv1, blackpillv2, blackpillv3.

Would this be agreeable to you? If yes, I can create a pull request, as you suggested.

Of course, all this is based on the presumption that there are not many more differences between V1.2 and V2 than just rom and ram. So please correct me if I have overseen something :)

dragonmux commented 1 year ago

it comes down to STM32F1 != STM32F4 and that different processors in the F1 and F4 series aren't quite alike - there's more than just SRAM and Flash differences as there are also CPU frequency differences, depending on the specific one there are also Flash erase sector size differences for the first erase sector, and a pile of other subtle things that are all just that bit different.

We very specifically don't want to try to do a combined platform that tries to least common denominator - that may not work out well in subtle ways leading to the platform being even more hard to debug than the funky problems people keep getting with the stlink-as-Bluepill platform which already tried that.

In regards a PR path forward - if you want to add a platform, blackpillv1_2, which targets your Blackpill board, having noted that it's not the same as Blackpill v1, then that'd be absolutely fine by us.

lenvm commented 1 year ago

Ok! All clear :) Thanks for the additional info!

To make it more clear that V1.2 is an STM32F4 board, rather than STM32F1, I would use blackpill-f4-v1_2. Is that also ok as a platform name?

It would make sense to also update the current blackpillv2 to blackpill-f4-v2, and someone could create the respective blackpill-f4-v3. As f4 is common between all of these I prefer blackpill-f4-v2 over blackpillv2-f4, as was suggested as a platform name in #1048.

dragonmux commented 1 year ago

Sure, that seems fine and would help prevent the "Blackpill v1.2's just a kind of Blackpill v1 right?" that we did - had not appreciated that v1.2 uses a F4 processor while v1 uses a F1.

We appreciate that for now it does duplicate a large amount of platform code, but in the broader context that's the option that's most acceptable till we can revamp the build system. :)

lenvm commented 1 year ago

Hi @dragonmux, before moving ahead in the direction discussed, I have done some additional reading and research.

In my opinion there are two options regarding the blackpillv2 platform:

  1. update it to blackpill-f4, supporting boards with microcontrollers STM32F411CE, STM32F401CE and STM32F401CC. My preference.
  2. create 3 platforms: blackpill-f411ce, blackpill-f401ce, blackpill-f401cc.

Let me explain by answering some questions:

Table 1: comparison of different boards <!DOCTYPE html>

microcontroller STM32F401CCU6 STM32F401CEU6 STM32F411CEU6
Frequency 84Mhz 84Mhz 100Mhz
ROM 256KB 512KB 512KB
RAM 64KB 96KB 128KB
Zephyr Project version V1.2 V3.0 V2.0
ROM and RAM values used by blackpillv2.ld (cae88d6) :white_check_mark:
hardware supported by current code (cae88d6) :x: :white_check_mark: :white_check_mark:

It has my preference to go for option 1., but if you decide that option 2. shall be taken, we shall do things consistently and create 3 different platforms with rom and ram values per microcontroller. In case of option 2, it may make sense to use a file with common code between these 3 "platforms", to reduce the amount of duplicate code.

Please decide as you see best. Then I'll move forward with implementing the changes in a branch and create a pull request.

dragonmux commented 1 year ago

Given how other projects have made this confusing by not using WeAct's naming scheme.. lets use the CPU names. We're not convinced there aren't subtle issues with differences in the peripheral hardware between the MCUs, and the frequency and Flash differences make compelling arguments to us to having tailored platform startup code and linker scripts.

We do not mind having 3 mostly entirely duplicate platforms for the 3 for now. De-duplication and re-converging the platforms is a big step in v2.0 anyway for the existing platforms (see also: stlink vs swlink) so we think choosing option 2 is the right choice of flexibility in the current build system.

lenvm commented 1 year ago

Hi @dragonmux, before I implement the 3 platforms blackpill-f411ce, blackpill-f401ce, blackpill-f401cc, can you please review #1467, to prevent having to replicate those changes for the 3 platforms?

dragonmux commented 1 year ago

Ah, yes, we'll try and get to that tonight

lenvm commented 1 year ago

I have taken a further look into the issue that the .bin file created is much larger when the code is compiled locally compared to compiled by koendv's GitHub.

I found the following:

I'm documenting this here as it may be useful for someone in the future who is looking into why the file size is much bigger when compiling using a different version of the ARM Toolchain.