cancel
Showing results for 
Search instead for 
Did you mean: 

Blockcopy not called when fetching Extra Data in ExtFlashSection

Dadigno
Associate II

I'm working on a custom STM32U5 board with TouchGFX. The board features an external NOR flash memory used for storing the ExtFlashSection (as documented here).

In my project testing, I aim to display a simple black and white image with a transparent area. Initially, I configured TouchGFX Designer to place both the "Section" and "Extra Section" within the internal flash (IntFlashSection), and everything functioned as expected. However, my application necessitates storing media files in the external memory.

To achieve this, I successfully linked the ExtFlashSection to the external NOR flash. Subsequently, I modified the positions of both the "Section" and "Extra Section" from IntFlashSection to ExtFlashSection.

Dadigno_8-1709215480676.png

after compilation this my external memory:

Dadigno_9-1709215673276.png

When running the code, a hard fault occurs. This is likely due to TouchGFX attempting to directly fetch data from external memory during the loading of the "Extra Section" data, instead of using the BlockCopy function.

This is the Trace:

Dadigno_10-1709215803456.png

And these are the registers: 

 

 

Dadigno_11-1709215927063.png

I came across this post and suspected it might be related to a known TouchGFX bug. I decided to move only the extra data to the IntFlashSection, which initially resolved the issue. However, when I tried changing the background image from bg_1.png to bg_2.png, a hard fault occurred again....here there are trace and registers

Dadigno_12-1709216891995.png

Dadigno_13-1709216917262.png

This time r1 is contains the base address for Extra Section of bg_2 in internal flash. So memory access should be ok....

Dadigno_14-1709217178339.png

What is the difference between bg_1.png and bg_2.png that could be causing this problem?

I would appreciate any suggestions or hints to resolve my problem.

7 REPLIES 7
GaetanGodart
ST Employee

Hello @Dadigno ,

 

From my understanding, SIGTRAP:Trace/breakpoint trap happens when the gdb (debugger used for embedded products) is not properly updated after using breakpoints.
Basically, you used breakpoints to debug your first problem which caused the current issue.

The solution seems to be to remove your breakpoints, disconnect the ST-Link, power off the board and reset everything.

If you restarted your computer from the time the issue happened it might have solved itself. 

 

Please tell me if your issue is solved.

 

Regards,

Gaetan Godart
Software engineer at ST (TouchGFX)

Probable that the External Memory is not memory-mapped properly at the time of the fault.

Check the configuration state of the QSPI. Unmapped memory will fault the processor

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
GaetanGodart
ST Employee

Hello @Dadigno ,

 

Have you been able to do what you wanted?

 

If one of the comment above was helpful, I invite you to select it as "Best answer" to increase the visibility and help people with the same issue as you.

 

Regards,

Gaetan Godart
Software engineer at ST (TouchGFX)

Hi Gaetan,

Thanks for your reply.

I understand that removing breakpoints isn't a solution since the application gets stuck even outside of debug mode.

I noticed a new release of TouchGFX (version 4.23.2) that includes a fix for "unaligned memory accesses" in cached bitmap data. This issue sounds similar to what I'm experiencing, so I'm planning to update to see if it resolves the problem.

 

Hi Tesla,

I'm trying to avoid memory-mapping my external memory. I've modified the block copy function to directly read from the memory using HAL, but when I set up Extra Section in ExtFlashSection region, the framework seems to bypass the block copy and use direct memory access instead. However, the "Section" region, which also resides in external memory, is still being read correctly via custom blockcopy. 

 

Hello @Dadigno ,

 

I hope this new version fixes your problem.

I came to that conclusion based on some stackoverflow posts such as this one : stackoverflow post and this one : stackoverflow post 2 

 

Also, if you uses an image / media with transparency, you need to store the alpha value of that media, so RGB565 and RGB888 do not work, you need instead ARGB8888 or L8_ARGB8888 (if you use maximum 256 different colors).

 

Keep me updated!

 

Regards,

Gaetan Godart
Software engineer at ST (TouchGFX)

Hi Gaetan, 

I've updated TouchGFX to the latest version, but unfortunately the problem persists. I've also tried using the ARGB8888 format: unique data section is generated and positioned correctly in the external memory range (0x90000000), but the memory access issue remains. ( no block copy is called )

 

Dadigno_0-1713165463258.png

Regards