Closed rei-vilo closed 3 years ago
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);
}
}
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.
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)
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.
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.
Describe the bug
Debugging the
blink
example using release 1.8.0 raises the error.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:
Export compiled binary
Open first Terminal window
Launch
st-util -p 3333
Open second Terminal window
Launch
/Users/USER/Library/Arduino15/packages/STM32/tools/xpack-arm-none-eabi-gcc/9.2.1-1.1/bin/arm-none-eabi-gdb
On the GDB console, run
Expected behavior
No SIGTRAP
Screenshots
See above
Board (please complete the following information):
Additional context
Thank you!