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

# Enable Debug connection in low power modes (DBGMCU->CR)
set *0xE0042004 = (*0xE0042004) | 0x7
# Set a breakpoint at main().
tbreak main

# Run to the breakpoint.

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.

  • \$\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, 2018 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, 2018 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, 2018 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, 2018 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, 2018 at 5:07

3 Answers 3


The error "Failure at line:6 in 'Target Software Startup Scripts'. Please edit the debug configuration settings." appears to have multiple causes. I'm guessing it is the default response when the 'load' command in the debugger script fails.

Here are two reasons I have run into:

  1. A fault in the FLASH memory in the MCU. You can verify this is the problem by downloading the STM32 ST-LINK Utility and trying to program the chip with verify.

  2. The ST-LINK seems to not like having the USB be plugged into a USB-C / Thunderbolt hub. It wants to be plugged right into the computer. (It may work a few times plugged into the hub, but this may be a ploy to lull you into complacency). In the past I have used a powered USB 3.0 hub with no problems but that may no longer work with Truestudio 9.3.1. BTW, the ST-LINK Utility does not seem to mind being plugged into the USB-C hub.

You can also sometimes get the loader to work by changing the code. I think this just moves bits around the bad memory location, if this is the case the problem will re-appear.

Another thing to try is powering up the target in 'bootloader' mode and then trying to program it.

Added 2/4/20: It also appears that anything that fails in the startup code before execution reaches main() can cause this. This is especially problematic if you are using C++, because constructors get called for all of the statically allocated instances before main() gets called. Hard faults in the constructors will cause this line 6 error.


I found the answer elsewhere but I will repeat it here for other people:

  1. Close Atollic TrueStudio (not sure if this is needed)
  2. Startup ST Utility
  3. Press the Reset button and keep it pressed
  4. Select Erase Chip (in Target menu)
  5. Release the Reset button
  6. The chip is erased
  7. Close ST Utility
  8. Startup Atollic TrueStudio

Debug should work now

source :Error when using debugging under Atollic TrueStudio / STM32

ST Utility: https://www.st.com/en/development-tools/stsw-link004.html


If the CPU ends up in the hard fault handler it means that clearly there is an obvious fault and you can find out which exact instruction caused it. Are you sure that you are enabling the FPU (or the startup code does it)?

Here is how Keil does it http://www.keil.com/support/docs/3716.htm (gcc should be the same, as register names are the same).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.