2019-11-28 07:10 AM
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.
Solved! Go to Solution.
2020-01-09 01:30 AM
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.
2020-01-09 12:34 AM
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
2020-01-09 01:30 AM
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.
2020-01-09 01:46 AM
Ah, yes, that's another classic. Glad you found it!
/Martin
2020-01-09 01:15 PM
> with the MCU STM32F746, single step debugging is impossible
It's possible. Read my posts in those topics:
https://community.st.com/s/question/0D50X0000BcRH33SQG/stm32h743-cortexm7-core-revision
2020-01-09 07:44 PM
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
2020-01-10 12:10 AM
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
2020-01-10 12:34 AM
Thank you so much for your clarificaton!! I realized that it's not from TouchGFX but from somewhere else.
2020-01-10 01:08 AM
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
2020-01-10 02:58 PM
> 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... :)