Actualmente estoy trabajando en un chip STM32H743VIT6 (en una placa de diseño propio), con la cadena de herramientas Atollic TrueStudio (ver. 9.0.0), usando un depurador ST-LINK en una placa de descubrimiento STM32F4 (firmware ST-LINK ver. V2J31S0).
Cuando intento depurar mi programa dentro del IDE de TrueStudio, me lanza el siguiente error:
Failure at line:6 in 'Target Software Startup Scripts'. Please edit the debug configuration settings.
Error writing data to flash
El script de inicio del depurador es simplemente predeterminado:
# Set flash parallelism mode to 32, 16, or 8 bit when using STM32 F2/F4 microcontrollers
# 2=32 bit, 1=16 bit and 0=8 bit parallelism mode
monitor flash set_parallelism_mode 2
# Load the program executable
load
# Enable Debug connection in low power modes (DBGMCU->CR)
set *0xE0042004 = (*0xE0042004) | 0x7
# Set a breakpoint at main().
tbreak main
# Run to the breakpoint.
continue
Ya que todo funciona bien hace un tiempo, traté de revertir mi código y encontré que una línea particular de código causa el problema.
#include <math.h>
// Something irrelevant...
double sin_deg (double degree)
{
double rad = degree / 180.0 * M_PI;
return sin(rad); // This line gives me problem
}
Escribí la función anterior con la intención de probar la funcionalidad de la biblioteca matemática en el MCU STM32H7. Si cambio return sin(rad); a algo sin funciones desde math lib, por ejemplo, return rad; (pero no return cos(rad); ), todo vuelve a funcionar bien . Esta es la única aparición de funciones de la biblioteca matemática.
Con la biblioteca matemática involucrada (por ejemplo, manteniendo el código no extraíble original return sin(rad); ), el proyecto sigue siendo perfectamente compatible y el programa compilado funciona como se esperaba si cargo el ejecutable con otras herramientas, por ejemplo, STM32CubeProgrammer, o simplemente presiona Ctrl + F11 dentro del IDE (configuré el comando Ejecutar con la CLI del STM32CubeProgrammer). En otras palabras, todo lo demás está bien, excepto que no se puede depurar .
También revisé el registro del depurador y me da esto:
Atollic TrueSTUDIO gdbserver for ST-Link. Version 4.2.0 (WIN32 2018-01-16 10:57:14 15656)
Copyright (c) 2018, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistant Mode : Disabled
LogFile Name : debug_log.txt
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
Waiting for debugger connection...
Debugger connected
STM32 device: program flash memory at address 8000000, length 664
STM32 device: flash programming successful 0x8000000
// ...
// Similarly for the consequent memory addresses... Until the followings
// ...
STM32 device: program flash memory at address 8009158, length 1512
STM32 device: flash programming successful 0x8009140
Debugger connection lost.
Shutting down...
Curiosamente, he comprobado el archivo elf con objdump, el programa NO alcanza 0x08009158; en su lugar, se detiene en 0x08009152.
Otra información relevante:
El proyecto y la plantilla de código se generaron con STM32CubeMX, con el controlador HAL de STM32. La compilación fue realizada por arm-atollic-eabi-gcc toolchain enviado con TrueStudio, con opciones:
-mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -std=gnu11 -D__weak=__attribute__((weak)) -D__packed=__attribute__((__packed__)) -DUSE_HAL_DRIVER -DSTM32H743xx -I../Inc -I../Drivers/STM32H7xx_HAL_Driver/Inc -I../Drivers/STM32H7xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../Drivers/CMSIS/Include -Og -ffunction-sections -fdata-sections -g -fstack-usage -Wall
La biblioteca de Runtime se establece en Newlib-standard.
Revisé brevemente el archivo de desensamblado del archivo ejecutable elf a través de objdump, la estructura general y las funciones de la biblioteca matemática se ven bien (y se ejecutan correctamente, de nuevo, excepto que no puedo depurar).
Después del error de lanzamiento del depurador, su sesión aún está activa, pero cuando intenté continuar con el programa, termina en HardFault_Handler (y permanece allí incluso después del restablecimiento, por IDE o el pin).
¿Alguien ha experimentado esto antes o tiene alguna idea o idea para esta situación? Gracias de antemano.