search

MaJerle / stm32-cube-cmake-vscode

STM32, VSCode and CMake detailed tutorial
MIT License
562 stars 59 forks source link

STM32U5xx crashes in startup file #26

Open lgacnik opened 2 days ago

lgacnik commented 2 days ago

I have followed this guide thoroughly and it worked great for MCUs I have worked so far with (F7 and F1), but with U5 I get some very-hard-to-explain behaviour. Build is flawless but debug is not. When entered the code execution stops at first instruction of startup file, then as soon as it runs to reach main, it crashes. Meaning it doesn't reach HardFault handler or any other fault handler. When I try stopping the execution debugger says it cannot stop and returns some undefined stack values.

The hardware I'm using:

The software I'm using:

Although I tried closely replicate CubeIDE's build setup, mainly through build flags since the rest should be very similar, the CubeIDE project build and runs perfectly. Meaning debugger reaches main without issues. Although I tried reverse engineering all the flags CubeIDE uses but I don't, it still seems something greater is missing since program crashes anyway. I've also tried substantially increasing heap and stack size but without improvement.

My only suspects were that either instruction set is not recognized or stack pointer is corrupted somehow. Instruction set should be a valid one as I'm using -mthumb flag. If it would be a hard fault I could at least check the source, which I cannot. The other one, the stack pointer likely corrupted, I'm not sure about that. When the first instruction of startup file tries to be executed and crashes, the stack address should be loaded into a register R0 like for any other STM32 MCU. And given the default linker file, I wouldn't have a clue why proper stack initialization wouldn't work out as it should.

But if I use the same actual setup for STM32F103 MCU (with different HAL, startup, and linker files plus CPU flags and the same hardware), debugger reaches main without issues.

I have appended my VSCode custom setup and would greatly appreciate if someone could give it a look. I have tried every possibility I had in mind but all in vain. test-vscode.zip

lgacnik commented 2 days ago

Here's the same setup that works but in CubeIDE. test-cubeide.zip

MaJerle commented 2 days ago

Luka,

I compiled your project, and run it with NUCLEO-U545RE.

image

I used the cortex-debug and it worked flawlessly. I removed the hardcoded paths to compiler/GDB since I have mine in the PATH config.

MaJerle commented 2 days ago

We've seen problem like this in the past, if hardware was not done correctly, and then GDB connect from the vscode used different flags than the one in the CubeIDE. One of the problems could be missing/wrong VCAP capacitors config, that could crash the CPU if connected with high CPU frequency on the ST-Link/JTAG.

In the vscode launch, you may investigate the option below, to lower connect frequency:

"serverArgs": ["--frequency 4000"]

I'm not saying this will fix the issue, but it might be the solution.

lgacnik commented 1 day ago

Tilen,

Thanks for insightful tips. Regarding the hardware, given that CubeIDE manages to debug until main on my hardware I'm still convinced there's a way for me to do the same from VSCode.

The VCAP in my case is 2x2.2uF MLCC since it's the 100 pin package with SMPS in parallel to LDO. However, I did just notice that the two capacitors are not distributed between two pins but are only positioned at one pin. This is definitely my fault. Other connections should be fine since I also followed STM32U5 hardware design guide during design of hardware. Really helpful by the way!

Regarding lowering the frequency, to my understanding that argument should lower the debugging clock speed to 4kHz. If yes then it appears the communication speed is still pretty high. Here's the starting log from the gdb-server terminal:

_------ Switching context ----- COM frequency = 3300 kHz Target connection mode: Default Reading ROM table for AP 0 @0xe00fefd0 Hardware watchpoint supported by the target ST-LINK Firmware version : V3J15M7 Device ID: 0x455 PC: 0xbf989f4 ST-LINK detects target voltage = 3.30 V TrustZone: Inactive ST-LINK device status: HALT_MODE GDB session, device event: 6 Stm32Device, pollAndNotify running... Enter STM32_SystemReset() function Enter STM32_InitAfterReset() function NVIC_DFSR_REG = 0x0000000B NVIC_CFGFSR_REG = 0x00000000 GDB session, device event: 4 Accepted connection on port 50000... Debugger connected Waiting for debugger connection... Waiting for connection on port 50000... GDB session thread running GdbSessionManager, session started: 2 GDB session, device event: 3 GDB session, device event: 3 GDB session, device event: 1 GDB session, device event: 1 ST-LINK device status: RUNMODE

In case you have further doubts regarding the hardware and have an extra minute, I've appended a schematic below. Check the "MCU supply" section for any irregularities. Except previously mentioned caps, all other are in their valid position next to relevant pins.

I will try adding missing capacitor (tantalum, not MLCC) to the relevant pin, as close as possible. If this doesn't work out then I will try to replicate NUCLEO-U545RE's MCU related external components.

Props to your VSCode custom setup! Makes my embedded development experience more exciting :) HMS100_SystemController-System controller.pdf

lgacnik commented 1 day ago

I have managed to try various speeds from 3300kHz down to 5kHz for GDB communication link. All of them failed. However, if neither of these clock settings would work then connection would have likely failed during establishing connection. Whereas in my case code execution stops at first instruction in startup file and then fails as it runs.

If it's relevant the stack undefined values are shown on the image below when I try to stop debugger after initial run. And if I chose to do anything else I get this: Could not step over: Cannot find bounds of current function (from exec-step --thread 1).

But if the CubeIDE manages to get the same piece of hardware working then the GDB communication speed isn't the main problem. Considering I use the lowest value for GDB communication speed CubeIDE is allowed to use.

Any other ideas? It's really strange that you get normal response with a NUCLEO evaluation board, meanwhile CubeIDE on my end proves my custom hardware is still able to run normally but not also VSCode setup, which in fact works for you.

If -mthumb is valid then I don't see a reason code execution would crash at first instruction of startup file due to any build flags. Surely, none of flags could cause such severe aftereffects (except optimizations perhaps), right? And considering linker and startup files are the same, is there really anything else that would play major role at running the MCU besides the mentioned factors? 2024-10-23 18_12_37-startup_stm32u535vetxq s - test-vscode - Visual Studio Code

MaJerle commented 1 day ago

I don't see obvious mistakes on your schematics. As long as you didn't forget at least ona VDD11 cap, it should be fine. I don't know why you have C9 capacitor on your button (boot0). This I'd remove in general.

I have managed to try various speeds from 3300kHz down to 5kHz for GDB communication link. All of them failed. However, if neither of these clock settings would work then connection would have likely failed during establishing connection. Whereas in my case code execution stops at first instruction in startup file and then fails as it runs.

Then I don't think this is the issue. Btw, parameter is always in "kilohertz", so for instance --frequency 4000 means 4MHz. I think lowest you can do is 1.8MHz.

If it's relevant the stack undefined values are shown on the image below when I try to stop debugger after initial run. And if I chose to do anything else I get this: Could not step over: Cannot find bounds of current function (from exec-step --thread 1).

This is definitely strange, but since it worked on my Nucleo, I don't see a reason why it wouldn't worked on your side. Linker script seems just fine to me.

But if the CubeIDE manages to get the same piece of hardware working then the GDB communication speed isn't the main problem. Considering I use the lowest value for GDB communication speed CubeIDE is allowed to use.

Yeah, in general I agree.

Any other ideas? It's really strange that you get normal response with a NUCLEO evaluation board, meanwhile CubeIDE on my end proves my custom hardware is still able to run normally but not also VSCode setup, which in fact works for you.

Do you have by chance any TrustZone enabled? Disable it if you have it.

If -mthumb is valid then I don't see a reason code execution would crash at first instruction of startup file due to any build flags. Surely, none of flags could cause such severe aftereffects (except optimizations perhaps), right? And considering linker and startup files are the same, is there really anything else that would play major role at running the MCU besides the mentioned factors?

-mthumb is definitely the right approach.

What I can offer you is a Google Meet and we go through via screen sharing meeting and review the situation. In that case, ping me to +33662774291 (whatsapp for instance).