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.

[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?

[suba512]

Well, I did the same this with the blue pill board. I used the STM32F103C8T6 while the one I am using in my project board is STM32F103CBT6TR which is pretty similar, I guess. So, I did flash the same toggle program for available pins in it, and I was able to see toggle on all pins which I configured.

[Andrew Neil]

As previously noted, a Blue Pill is most likely not a genuine STM32.

Have you tried this 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 tried in NUCLEO-H753ZI development board too, but the toggle did happen for all selected board and its genuine like apart from the blue pill board STM32F103C8T6. Right now, I kind of suspect both the hardware design and the code too, so we are trying to analyze in both. Is there any other approach for this?