Skip to main content
KShim.1738
Associate III
Nov 28, 2019 3:10 PM UTC
Solved

[SOLVED] hal.initialize() causes hard fault. -- actually __libc_init_array() not called.

I'm porting toughgfx button example to rt-thread. I tested the environment with led blinking.

My environment is as below.

tool chains: scons + gas/gcc/g++

debugging : openocd + gdb

flash program : STM32CubeProgrammer with openjdk and openjfx

RTOS: rt-thread

Board: stm32f746g-disco

I merged the touchgfx button example into rt-thread. And then I began to experience a hard fault. It starts with touchgfx::touchgfx_init(). I checked that I have no problem with cpp codes, such as new operator and STL.

  at touchgfx-button/Middlewares/ST/TouchGFX/touchgfx/framework/include/common/TouchGFXInit.hpp:86

86     HAL& hal = getHAL<HALType>(dma, display, tc, width, height);

  at touchgfx-button/Middlewares/ST/TouchGFX/touchgfx/framework/include/common/TouchGFXInit.hpp:87

87     hal.initialize();

void OSWrappers::initialize()

0801c9a0 <_ZN8touchgfx3HAL10initializeEv>:

 801c9a0:    b510      push  {r4, lr}

 801c9a2:    4604      mov   r4, r0

 801c9a4:    f7f2 f986    bl   800ecb4 <_ZN8touchgfx10OSWrappers10initializeEv>

 801c9a8:    6860      ldr   r0, [r4, #4]

 801c9aa:    6803      ldr   r3, [r0, #0]

 801c9ac:    68db      ldr   r3, [r3, #12]

 801c9ae:    4798      blx   r3

After the call to OSWrappers::initialize(), r3 was 0x9db545a1.

 801c9ae:    4798      blx   0x9db545a1

For your information, my lds file is...

================= lds file =================

{

RAM (xrw)   : ORIGIN = 0x20000000, LENGTH = 320K

FLASH (rx)   : ORIGIN = 0x08000000, LENGTH = 1024K

QUADSPI (r)  : ORIGIN = 0x90000000, LENGTH = 16M

}

There should be no codes in QUADSPI area. But I don't know what that code is. Would you please advise me with my lds file?

I've enclosed the linker script file.

This topic has been closed for replies.
KShim.1738
KShim.1738Best answer
Associate III
Jan 9, 2020 9:30 AM UTC

Finally I found the problem.

The environment for debugging with STM32F746G-DISCO and libtouchgfx-float-abi-hard.a is not good. First of all with the MCU STM32F746, single step debugging is impossible. And the library without source makes it harder.

It was because that the constructors were not called properly before main(). It caused the Hard Fault.

Thank you.

10 replies

Martin KJELDSEN
Principal III
Jan 9, 2020 8:34 AM UTC

Hi,

I can tell you what goes on in HAL::initialize();

Initialization of OSWrapper, DMA, touchcontroller and configuration of interrupts.

OSWrappers::initialize() typically configures framebyffer semaphores and a vsync queue. Which OSWrapper are you using?

/Martin

KShim.1738
KShim.1738AuthorBest answer
Associate III
Jan 9, 2020 9:30 AM UTC

Finally I found the problem.

The environment for debugging with STM32F746G-DISCO and libtouchgfx-float-abi-hard.a is not good. First of all with the MCU STM32F746, single step debugging is impossible. And the library without source makes it harder.

It was because that the constructors were not called properly before main(). It caused the Hard Fault.

Thank you.

Martin KJELDSEN
Principal III
Jan 9, 2020 9:46 AM UTC

Ah, yes, that's another classic. Glad you found it!

/Martin

Piranha
Principal III
Jan 9, 2020 9:15 PM UTC
KShim.1738
Associate III
Jan 10, 2020 3:44 AM UTC

Thank you for your advice.

It's TouchGFX I ported to new OS, rt-thread which is not popular outside China. TouchGFX is for GRAPHIC and has a lot of relatively big size image and font data. So I need to program EXTERNAL FLASH together with internal flash. That's why I'm using STM32CubeProgrammer.

I knew about the Segger J-Linker. I'm not sure whether other flash tools with Segger J-Linker has this capacity of flashing external flash. For example, if openocd with Segger J-Linker can program the external flash, I absolutely like to use it. But I'm not sure about that. During the conversion I shall risk losing my board.

Kyle

Martin KJELDSEN
Principal III
Jan 10, 2020 8:10 AM UTC

The size of your images and fonts are solely determined by you :) The quality and size of these assets determine the data placed in flash - It's not a TouchGFX thing, it's the actual pixel data from your assets (fonts, images).

/Martin

LDoyl
Associate II
Feb 25, 2021 3:13 PM UTC

I had a hard fault error that came up when ever the external FLASH on a '469-Disco board was accessed. In the CubeIDE it looked like the data was in the FLASH -so what was the problem????

It turned out that STLINK could access the FLASH but the program couldn't. The clue to fixing this problem was the youtube https://www.youtube.com/watch?v=237lPdMsDZsL . I needed to copy files into the BSP folder for the touchscreen and QSPI FLASH which I copied from one of the demos. Also some of the parameters that CubeMX generated for the FLASH in the main.c appeared to be incorrect. These were replaced by the settings from the demo.

Hope this helps someone save some time.