1
\$\begingroup\$

I am currently working on a STM32H743VIT6 chip (on a self-designed board), with the Atollic TrueStudio toolchain (ver. 9.0.0), using a ST-LINK debugger on a STM32F4-Discovery board (ST-LINK firmware ver. V2J31S0).

When I try to debug my program within the TrueStudio IDE, it throws the following error to me:

Failure at line:6 in 'Target Software Startup Scripts'. Please edit the debug configuration settings. 

Error writing data to flash

The debugger startup script is just default:

# 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

Since everything works fine a while ago, I tried to revert my code and found that a particular line of code causes the problem.

#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
}

I wrote the function above with the intention to test the math library's functionality on STM32H7 MCU. If I change the return sin(rad); to something without functions from math lib, for example return rad; (but not return cos(rad);), everything works fine again. Here is the only occurrence of functions from math library.

With the math library involved (say keeping the original undebuggable code return sin(rad);), the project is still perfectly compliable, and the compiled program is working as expected if I load the executable with other tools, say STM32CubeProgrammer, or just press Ctrl+F11 inside the IDE (I configured the Run command with the STM32CubeProgrammer's CLI). In other words, everything else is fine except cannot debug.

I further checked the debugger log and it gives me this:

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...

Interestingly, I checked the elf file with objdump, the program does NOT reach 0x08009158; instead, it stops at 0x08009152.

Other relevant information:

The project and code template was generated with STM32CubeMX, with STM32's HAL driver. Build was done by arm-atollic-eabi-gcc toolchain shipped with TrueStudio, with options:

-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

Runtime library is set to Newlib-standard.

I briefly checked through the disassembly file of the executable elf file via objdump, the overall structure and the math library functions look fine (and runs correctly - again, except cannot debug).

After the debugger throwing error, its session is still alive, but when I tried to continue the program it ends up in HardFault_Handler (and stays there even after reset, by IDE or the pin).

Has anyone experienced this before, or have any clue/idea for this situation? Thanks in advance.

\$\endgroup\$
  • \$\begingroup\$ What artifact are you loading via the external tool? Is it the same as the one that your debug startup script loads? I think by default the debugger loads the .elf, so if your external tool uses a .hex file, that could be a clue. \$\endgroup\$ – ajb Sep 11 '18 at 18:55
  • \$\begingroup\$ The STM32Programmer utility accepts all the common formats of files. Here it is using .elf, and there is no other formats of executables in my workspace, so this should be fine. Plus, just not using math functions will bring back everything working, so I think the file format shouldn't be an issue here. \$\endgroup\$ – Yunfan Li Sep 12 '18 at 14:37
  • \$\begingroup\$ It's possible that something about the structure of your .elf when the math function is included is triggering a bug somewhere in the debug chain (the ST-Link gdbserver, driver, or even firmware). Maybe start a debug session, then read out the flash and disassemble/compare to what you readout after using the external tool? \$\endgroup\$ – ajb Sep 12 '18 at 15:05
  • \$\begingroup\$ Using other external tools provided by ST to verify flash against executable file gives me good result. Probably it is a bug for the debugger driver or firmware, I guess. Interestingly, if I have the math lib compiled in but never execute (the lib function inside elf but never called), the debug session works fine; but if math function is called, the session fails at beginning. Should it be failing only when the function is called? \$\endgroup\$ – Yunfan Li Sep 13 '18 at 5:03
  • \$\begingroup\$ Just to avoid confusion above: if I use the debug session integrated (and shipped with) Atollic and it fails due to using math function (maybe?), the download won't even complete and of course, the image on the chip is corrupted. It is verified to be OK only if the debug session works. \$\endgroup\$ – Yunfan Li Sep 13 '18 at 5:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.