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

[KShim.1738]

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.

[Martin KJELDSEN]

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 · Accepted solution]

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]

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

/Martin

[Piranha]

> with the MCU STM32F746, single step debugging is impossible

It's possible. Read my posts in those topics:

https://community.st.com/s/question/0D50X0000A4pIcQSQU/stm32f746-cortexm7-silicon-bug-singlestep-lands-in-interrupt-handler

https://community.st.com/s/question/0D50X0000BcRH33SQG/stm32h743-cortexm7-core-revision

[KShim.1738]

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]

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

[KShim.1738]

Thank you so much for your clarificaton!! I realized that it's not from TouchGFX but from somewhere else.

[Martin KJELDSEN]

TouchGFX contains tools that will interpret all your assets (font- and imageconverter) and turn the images and glyphs into pixel data for a specific size and format depending on your configuration. e.g. 16-bit vs 24-bit because these pixels have to be copied to the framebuffer which must match in depth.

/Martin

[Piranha]

> During the conversion I shall risk losing my board.

You don't risk anything, as it can be converted back to ST-LINK. The conversion (both ways) takes less than a minute... :)