Electronic – Atollic STM32H7 + ST-LINK Error writing data to flash with math library

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.