Startup problem

[DWeie]

Hello,

I've built a semi-functional demo project for a client of ours using touchGFX 4.10.0 through STM32CubeIDE for a STM32F746BGT6 processor.

One of the remaining issues I need to resolve has to do with the startup of touchGFX. When I flash the code and run a debug session, I am able to see the screen I expect, and touchGFX responds to button presses etc. However, if I exit the debug session and power cycle my device, the screen does not display properly.

As a test I painted the screen green after setting up the hardware, and before calling the touchGFX taskEntry. When I did this the screen remained green after a POR. This indicates that the hardware initialization is correct and is being completed, but touchGFX does not write to the frame buffer after starting.

In order to force a redraw I added a slide screen action after a button press event. When pressing the button (which works in debug) there is no change on the display.

This is difficult to debug since the project runs when I have a debugger attached.

Has anyone encountered a similar problem before?

Don

[cameronf]

Don't have any touchgfx specific ideas but have another longshot idea.

Do you have any memory buffers declared as byte arrays but that would get used with 32-bit aligned access? Normally when the mcu does 32bit aligned access on a non-32bit aligned address it faults, but with the debugger attached sometimes the fault is masked and works fine.

[DWeie]

Thanks for the reply. I took a look at the project with your suggestion in mind, but I did not find anywhere where a misalignment would be occurring. Based on some tests with outputs it seems that my program runs all the way up to the call to    

touchgfx::HAL::getInstance()->taskEntry();

It seems like there is a misconfiguration occurring that is causing touchGFX to fail when it is called. The only change I am making to the generated code is to add a KeySampler to the hal initialization.

[cameronf]

Are you calling __HAL_RCC_CRC_CLK_ENABLE() anywhere? This needs to get enabled before starting the touchgfx task or it will crash. I think having the debugger attached powers some clocks depending on options so could possibly mask the problem of not calling this? Other than that don't have any ideas.

[DWeie]

Thanks for the help cameron. I double checked that I was enabling the clock and the MXCube generated initialization functions were taking care of that.

[DWeie]

To anyone reading this, I was able to resolve my problem. The major issue was that touchGFX was trying to access assets stored in QUADSPI, and this QUADSPI was not being properly configured during startup. There were some setup commands that it needed. I'm not sure what it was about debug mode that suppressed this problem. I'll look into it once I can and update this post if I have more information.

[BPark.3]

Hi Don, having the same issue where my code will only work in debug otherwise the screen is not loading images from QSPI properly, have you any more info on how this was resolved/ what the debugger is doing that fixes the issue?

[DWeie]

Hey Ben,

I'm sorry I can't offer more information about what exactly it was about debug mode that was suppressing the problem. I can tell you what the solution was in my case. After setting up the QUADSPI peripheral registers in the ST processor, I needed to issue a reset to the QUADSPI then send configuration commands to the part. This ensured that the QUADSPI was in the state that the ST processor expected it to be in. After doing this I had no more issues. Most likely the details of what exactly you will need to do will be found in the datasheet of your QUADSPI part. Hope this helps.

Don

[HP]

@BPark.3​ Hey there - just pinging everyone I can see having the same issue as me. I think I have found a fix - maybe you can give it a go to try and verify this?

https://community.st.com/s/question/0D50X0000BI1CvjSQF/external-vs-internal-flash-memory-for-touchgfx-assets