SIG TRAP on STM32F103CBT6TR

[suba512]

I am working on a custom board with STM32F103CBT6TR. Initially, flashing the code resulted in a Hard Fault error, but now it consistently enters a SIGTRAP even after removing all breakpoints. Additionally, the GPIO pins are not toggling as expected. The code is attached as notepad file for reference. Can someone give a solution to this, thank you.

 

SIGTRAP on STM32F103CBT6TR usually points to a breakpoint or debugging issue in the code, possibly triggered during execution. It’s important to check the debug configuration and ensure there are no unintended breakpoints. I found similar discussions while exploring michat apk, which helped me understand this better.

[suba512]

Well, I have removed every breakpoint like cleared that used to be present in breakpoint section, but now in debug why it kind of stops in HAL_Delay like it goes to toggle command and then the delay but after that if i resume it just goes out of program like shows this in debug

Thread #1 [main] 1 [core: 0] (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)

0x1ffff766

<signal handler called>() at 0xfffffff1

0x47706008

<signal handler called>() at 0xfffffff9

HAL_GetTick() at stm32f1xx_hal.c:306 0x80004ec

HAL_Delay() at stm32f1xx_hal.c:382 0x8000528

main() at main.c:102 0x8000170

 

[Andrew Neil]

---

@suba512 wrote:

I am working on a custom board with STM32F103CBT6TR.

---

Please give full details of this board - see:

How to write your question to maximize your chances to find a solution

 

If it's a Blue (or other coloured) Pill board, note that these are not ST products, and likely contain fake chips.

Can you reproduce this issue on a genuine ST board?

[suba512]

Part Number STM32F103CBT6TR (MCU IC)

Environment

• Toolchain: STM32CubeIDE ( v1.18.0).

• Debugger: ST‑Link 

Hardware: Custom board based on STM32F103CBT6TR.

schematics: This is our own design, so we cannot share the full schematics publicly. However, the relevant connections are:

• PA1 connected to LED (with series resistor).

• Standard power supply and oscillator circuitry as per datasheet recommendations.

• Internal RC oscillator used for initial testing

Details

• Initially, when attempting to toggle GPIO pin PA1 using HAL functions (HAL_GPIO_TogglePin or HAL_GPIO_WritePin), the MCU immediately entered the HardFault handler after flashing.

• Later, during debugging, instead of HardFault, the debugger reported a SIGTRAP (Trace/breakpoint trap).

• Currently, stepping into HAL_Delay() leads to an IACCVIOL (Instruction Access Violation) fault.

• Observed behavior: LED does not toggle, program halts in HardFault, SIGTRAP, or IACCVIOL depending on run/debug mode.

• Debugger stack trace shows execution stuck in HAL_GetTick() inside HAL_Delay(), suggesting SysTick is not firing.

Expected Behavior: GPIO pin PA1 should toggle every 2000 ms using HAL_Delay, with no HardFault, SIGTRAP, or IACCVIOL errors.

Flash the following code on STM32F103CBT6TR custom board ,

• Observe that after flashing, the MCU enters HardFault immediately, which result in toggle or led blink connected to it.

• In debug mode, stepping into HAL_Delay triggers SIGTRAP with in fault analyzer, I see this one is getting on IACCVIOL, when like HAL_Delay line is getting executed in debug but before execution of delay, there is no fault seen in fault analyzer.

• Occurrence Systematic: occurs every time the program is run on the custom board.

• Sanity Checks

  • Verified GPIO initialization code matches CubeMX generated template.

  • Confirmed HAL_Init() and SystemClock_Config() are called before GPIO use.

  • Checked that SysTick interrupt is not firing (HAL tick not incrementing).

  • No breakpoints set, but debugger still halts with SIGTRAP/IACCVIOL.

 

[Andrew Neil]

Can you reproduce this issue on a genuine ST board?

[TDK]

> HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_0);

> HAL_Delay(2000);

 

> Expected Behavior: GPIO pin PA1 should toggle every 2000 ms 

 

Do you want to toggle PA0 or PA1?

 

This is effectively a repost from this:

Hard Fault Handler error in STM32F103CBT6TR - STMicroelectronics Community

 

The solution is the same: buy a board that works.

 

[gbm]

Verify that BOOT0 pin is connected to ground - directly or via a resistor.

Also, if you are unsure about chip type (might be remarked F103C6) try to reduce RAM size in linker script to 10KiB.

[suba512]

I will see to try on this and will update you. Thank you.