search

platformio / platform-ststm32

ST STM32: development platform for PlatformIO
https://registry.platformio.org/platforms/platformio/ststm32
Apache License 2.0
389 stars 305 forks source link

STSTM32 platform is using wrong version of toolchain-gccarmnoneeabi package #492

Closed Copper-Bot closed 3 years ago

Copper-Bot commented 3 years ago

Problem:

STSTM32 use the last toolchain gccarmnoneabi package (1.90201.191206) to build MBED framework (and surely others).

I never had problems with that, until recently playing with STM32G4 family. For some reason, the compiler is doing something wrong, and I can't upload or debug my boards using JLINK probes, without having the classic MBED code error blinking led. The only solution is to roll back the toolchain version.

Expected behaviour:

STSTM32 should normally use a version between 1.60301.0 and <1.80000.0 according to .platformio/platforms/ststm32/platform.json file.

A possible explanation here by maxgerhardt about why the last toolchain package is used instead.

Related problem:

By using 9.2.1 package for a project, PIO Core does not seem to acknowledge the use of this package.

So, every time a pio update is carry out, the package is removed ... but has to be downloaded again if a STSTM32 PIO project is run again.

Temporary fix:

Force PIO to use an old version of the package in the platformio.ini of the project by adding:

platform = ststm32
framework = mbed
platform_packages =
    toolchain-gccarmnoneeabi @ <1.80000.0

By doing so, toolchain-gccarmnoneeabi 1.70201.0 (7.2.1) package is used instead of the last one. And this resolve problems related to STM32G4 family (and possibly others family ?).

I am using the last PIO core (5.1.0), last STSTM32 platform (11.0.0) and last MBED framework package (6.60600.210128).

I observed this behaviour on two OS:

valeros commented 3 years ago

Hi @Copper-Bot ! That's strange, could you please also try a bit newer v9.3.1:

platform = ststm32
framework = mbed
platform_packages =
    toolchain-gccarmnoneeabi @ ~1.90301.0
Copper-Bot commented 3 years ago

Hello @valeros,

Same behaviour with v9.3.1 toolchain package.

Build is fine, upload is fine using a JLINK probe, but program goes to MBED blink error sequence as soon as it is uploaded. The only solution is to plug/unplug the board to get the program running. And, of course, debug can't work on theses conditions.

After enabling serial output, I managed to get this MBED error fault message:

++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R   0: 00000000
R   1: 00000001
R   2: E000ED00
R   3: 00000000
R   4: 00000001
R   5: 00000000
R   6: 00001388
R   7: 080021AD
R   8: 00000000
R   9: 00000000
R  10: 00000000
R  11: 00000000
R  12: 000975E0
SP   : 200012D8
LR   : 08006CE9
PC   : 08003E48
xPSR : 61000000
PSP  : 200012B8
MSP  : 2001FFC0
CPUID: 410FC241
HFSR : 40000000
MMFSR: 00000082
BFSR : 00000000
UFSR : 00000000
DFSR : 00000000
AFSR : 00000000
MMFAR: 000007F1
Mode : Thread
Priv : Privileged
Stack: PSP

-- MbedOS Fault Handler --

++ MbedOS Error Info ++
Error Status: 0x80FF013D Code: 317 Module: 255
Error Message: Fault exception
Location: 0x8003E48
Error Value: 0x20002984
Current Thread: rtx_idle Id: 0x20000D24 Entry: 0x80020C9 StackSize: 0x300 StackMem: 0x20001068 SP: 0x200012D8
For more info, visit: https://mbed.com/s/error?error=0x80FF013D
-- MbedOS Error Info --

It seems to be kind of related to this MBED issue: https://github.com/ARMmbed/mbed-os/issues/10339

But in my case, I am just trying to build the official MBED blinky.

Another possible explanation: I am using a custom board with a STM32G474VE. But I have verified multiple times the custom targets MBED files, and all seems good (only two files in my case, PeripheralPins.c, and PinNames.h).

If I switch to MBED 5.15.6 PIO package (and after copy/past all STM32G4 target files introduce from MBED 6), then the problem disappears.

Unfortunately, I don't have an official board from ST (a nucleo with a STM32G4) to verify if the problem comes from my board in particular. I don't have this problem with other board that use different brands of STM32.

The issue does not appear if I am using DFU as upload_protocol. Only appear with a JLINK probe.

The issue does not appear with MBED-CLI 1, using gcc-arm-none-eabi 9-2019-q4-major as precise here.

What I can't figure it out is why (and how) the toolchain version is affecting the STM32G4 family with a MBED 6 program when using JLINK probes ... I first open the issue here, because I thought it was a toolchain version error from the PlatformIO package, but maybe this is a deeper issue that comes from MBED side.

This maybe need further investigating on my part (using at least a nucleo board), to pinpoint precisely the problem.

valeros commented 3 years ago

If I'm not mistaken, gcc-arm-none-eabi 9-2019-q4-major is 9.2.1 as well. There was somewhat similar issue #478 with STM32L, so there is a chance that there is something wrong with the mbed port for STM32G4 as well.

Copper-Bot commented 3 years ago

You are right, this is the same version ... so it should have worked... My issue title is kind of wrong then, because gcc-arm-none-eabi 9-2019-q4-major (xPack 9.2.1) is the recommended version used by MBED.

I'm gonna investigate why it works using MBED-CLI but not with PIO, using the same toolchain and the same MBED OS 6.6.0 version (I tried with PIO and MBED 6.7.0 but the issue still appears).

Copper-Bot commented 3 years ago

Well @valeros it was a debug issue.

I was forcing PIO to build_type = debug in my projects, to avoid rebuilding the sources between upload and debug. So "-Og -g2 -ggdb2" flags were present at all time according

BUT, for some reason, I just find out that using the combo "-Og" + MBED 6 + STM32G4 + toolchain 9.2.1 + PlatformIO result in a MBED HardFault error after programming with a JLINK probe. Really weird.

The only solution for me is to force PIO to remove "-Og" flag:

build_type = debug
debug_build_flags = -O0 -g2 -ggdb2

In that way, I can upload without having a MBED error, and fully debug with a JLINK probe.

When testing with MBED-CLI using debug profile (which use "-Og" flag), I don't have this issue.

So my guess is, maybe there is some missing debug flag for debugging a STM32G4 using PlatformIO ? I see a lot of flags in the debug profile file, but I really don't know...

My next step is to do some test with a Nucleo G4, just to be sure.

I am closing this issue since it was not related to the toolchain version of the package.

Copper-Bot commented 3 years ago

Update: Adding the missing flags from MBED debug profile file unlock the use of "-Og" flag into PlatformIO without having trouble using a JLINK probe:

build_type = debug
debug_build_flags = -Og -DMBED_DEBUG -DMBED_TRAP_ERRORS_ENABLED=1 -g2 -ggdb2

Maybe the -DMBED_DEBUG flag should be added by default in PIO when MBED framework is used ?

EDIT: Same problem with a NUCLEO_G474RE. Without adding mbed flags (at least -DMBED_DEBUG), then upload/debug using a JLINK probe will fail on the board.

Same problem will appear if the user tries to debug using the embedded STLINK on the board without addingmbed flags.