Skip to main content
KShim.1738
Associate III
November 28, 2019
Solved

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

  • November 28, 2019
  • 10 replies
  • 3387 views

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.
Best answer by KShim.1738

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
January 9, 2020

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
January 9, 2020

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
January 9, 2020

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

/Martin

Piranha
Principal III
January 9, 2020
KShim.1738
Associate III
January 10, 2020

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
January 10, 2020

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
February 25, 2021

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.