Nucleo STM32F401RE: Program received signal SIGTRAP, Trace/breakpoint trap.

[rei-vilo]

Describe the bug

Debugging the blink example using release 1.8.0 raises the error.

Program received signal SIGTRAP, Trace/breakpoint trap.

I'm using release 1.8.0 as executable built with release 1.9.0 doesn't run. See #1205

To Reproduce

Steps to reproduce the behavior:

1. Launch Arduino IDE
2. Select Blink example
3. Select following options

4. Export compiled binary

5. Open first Terminal window

6. Launch st-util -p 3333

7. Open second Terminal window

8. Launch /Users/USER/Library/Arduino15/packages/STM32/tools/xpack-arm-none-eabi-gcc/9.2.1-1.1/bin/arm-none-eabi-gdb

9. On the GDB console, run

GNU gdb (xPack GNU Arm Embedded GCC, 64-bit) 8.3.0.20190709-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin14.5.0 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) file /var/folders/wn/n7qqb8ss0k3bvpqwfcdwp_7r0000gn/T/arduino_build_931168/Blink.ino.elf
Reading symbols from /var/folders/wn/n7qqb8ss0k3bvpqwfcdwp_7r0000gn/T/arduino_build_931168/Blink.ino.elf...
(gdb) set remotetimeout 2000
(gdb) target extended :3333
Remote debugging using :3333
0x61000000 in ?? ()
(gdb) monitor reset halt
(gdb) load
Loading section .isr_vector, size 0x194 lma 0x8000000
Loading section .text, size 0x4f2c lma 0x8000194
Loading section .rodata, size 0x510 lma 0x80050c0
Loading section .ARM, size 0x8 lma 0x80055d0
Loading section .init_array, size 0xc lma 0x80055d8
Loading section .fini_array, size 0x8 lma 0x80055e4
Loading section .data, size 0x20c lma 0x80055ec
Start address 0x8003234, load size 22520
Transfer rate: 16 KB/sec, 2815 bytes/write.
(gdb) monitor reset init
(gdb) list loop()
27	  // initialize digital pin LED_BUILTIN as an output.
28	  pinMode(LED_BUILTIN, OUTPUT);
29	}
30	
31	// the loop function runs over and over again forever
32	void loop() {
33	  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
34	  delay(1000);                       // wait for a second
35	  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
36	  delay(1000);                       // wait for a second
(gdb) break 33
Breakpoint 1 at 0x8000216: file /Applications/IDE/Arduino.app/Contents/Java/examples/01.Basics/Blink/Blink.ino, line 33.
(gdb) enable 1
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Program received signal SIGTRAP, Trace/breakpoint trap.
main ()
    at /Users/USER/Library/Arduino15/packages/STM32/hardware/stm32/1.8.0/cores/arduino/main.cpp:65
65	    if (serialEventRun) {
(gdb) frame 0
#0  main ()
    at /Users/USER/Library/Arduino15/packages/STM32/hardware/stm32/1.8.0/cores/arduino/main.cpp:65
65	    if (serialEventRun) {
(gdb) info frame 0
Stack frame at 0xa037a08:
 pc = 0x80036b4 in main
    (/Users/USER/Library/Arduino15/packages/STM32/hardware/stm32/1.8.0/cores/arduino/main.cpp:65); saved pc = <not saved>
 Outermost frame: Cannot access memory at address 0xa037a04
 source language c++.
 Arglist at 0xa037a00, args: 
 Locals at 0xa037a00, Previous frame's sp is 0xa037a08
Cannot access memory at address 0xa037a00
(gdb) 

Expected behavior

No SIGTRAP

Screenshots

See above

• OS: macOS 10.15.7
• Arduino IDE version: 1.8.13
• STM32 core version: 1.8.0
• Tools menu settings if not the default: [e.g. Newlib Standard, No Serial] See above
• Upload method: [e.g. STLink] MSD

Board (please complete the following information):

• Name: Nucleo F401RE
• Hardware Revision: MB1136 rec.C
• Extra hardware used if any: none

Additional context

Thank you!

[fpistm]

Hi @rei-vilo
honestly I'm not able to reproduced.
The blink sketch is a base and works fine, the 1.9.0 has been released since several month and if it does not works I guess it will be reported since a while. I've also debug on the Nucleo F401RE several time using gdb and openOCD without any issue (Under Windows and Linux) as it was used for a COVID respirator project. When releasing the 1.9.0 I've made several test under Mac and didn't found any issue.

The main changes for Nucleo F401RE is now it uses the HSE bypass instead of the HSI.
So maybe your boards has an issue with the clock.

You an simply try by redefining the default SystemClock_Config on top of your sketch:

extern "C" void SystemClock_Config(void)
{
  RCC_ClkInitTypeDef RCC_ClkInitStruct;
  RCC_OscInitTypeDef RCC_OscInitStruct;

  /* Enable Power Control clock */
  __HAL_RCC_PWR_CLK_ENABLE();

  /* The voltage scaling allows optimizing the power consumption when the device is
     clocked below the maximum system frequency, to update the voltage scaling value
   regarding system frequency refer to product datasheet.  */
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE2);

  /* Enable HSI Oscillator and activate PLL with HSI as source */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = 0x10;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
  RCC_OscInitStruct.PLL.PLLM = 16;
  RCC_OscInitStruct.PLL.PLLN = 336;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV4;
  RCC_OscInitStruct.PLL.PLLQ = 7;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) {
    /* Initialization Error */
    while (1);
  }
  /* Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2
     clocks dividers */
  RCC_ClkInitStruct.ClockType = (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2);
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != HAL_OK) {
    /* Initialization Error */
    while (1);
  }
}

[rei-vilo]

Thank you for your answer. Adding the extern "C" void SystemClock_Config(void) function did the trick with release 1.9.0.

Also, I had to edit boards.txt and change Nucleo_64.menu.pnum.NUCLEO_F401RE.node=NODE_F401RE for Nucleo_64.menu.pnum.NUCLEO_F401RE.node=NUCLEO in order to upload, as the board shows up as NUCLEO and not NODE_F401RE.

Next step: testing debugging.

[rei-vilo]

Still non luck with debugging.

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at main.cpp:70
70	    serialEventRun();
(gdb) frame 0
#0  main () at main.cpp:70
70	    serialEventRun();
(gdb) info frame 0
Stack frame at 0xa037a08:
 pc = 0x800031e in main (main.cpp:70); saved pc = <not saved>
 Outermost frame: Cannot access memory at address 0xa037a04
 source language c++.
 Arglist at 0xa037a00, args: 
 Locals at 0xa037a00, Previous frame's sp is 0xa037a08
Cannot access memory at address 0xa037a00
(gdb)

• GNU gdb (xPack GNU Arm Embedded GCC, 64-bit) 8.3.0.20190709-git
• st-util --version v1.6.1

[fpistm]

About the node name, it is a known issue, old board have this naming. Updating the STLink fw will solve this issue, I think.
Else, the name "NUCLEO" can be added to the node name in boards.txt:
https://github.com/stm32duino/wiki/wiki/FAQ#when-using-mass-storage-upload-method-following-error-is-displayed

For the clock issue, it seems your board have an issue with the HSE Bypass (clock provided by the STLink).

For the debugging I will not be able to help. Anyway I'm wondering as it seems you have a STLink clock issue then debug could be impacted.

[rei-vilo]

I performed an update of the ST-Link V.2.1 firmware, to no avail.

The board might be too old, with serial number MB1136 rev.C.

I'll try with other Discovery boards I have at hand, STM32F429I and STM32F746G.

So I'm closing the thread.