2024-02-29 06:43 AM
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.
after compilation this my external memory:
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:
And these are the registers:
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
This time r1 is contains the base address for Extra Section of bg_2 in internal flash. So memory access should be ok....
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.
2024-03-05 05:45 AM
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,
2024-03-05 06:27 AM
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
2024-03-26 04:01 AM
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,
2024-03-29 12:16 AM
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.
2024-03-29 12:27 AM
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.
2024-04-02 03:14 AM
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,
2024-04-15 12:18 AM
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 )
Regards
2024-04-19 05:14 AM
Hello @Dadigno ,
Let me summarize your issue :
1) Full black background (RGB565)
Section int | extra section int => success
Section ext | extra section ext => hardfault
Section ext | extra section int=> success
2) Black bakckground with tranparency in the middle (ARGB8888)
Section int | extra section int => success
Section ext | extra section ext => hardfault
Section ext | extra section int=> hardfault
Your images do not use L8.
If your images do not use L8, the extra section is not used. So changing the extra section location for the full black background should not have changed anything.
Can you please send use some informations :
- linker script
- clockCopy function
- screenshot of your parameters in Designer :
- screenshot of you x-cube-touchgfx configuration in STM32CubeMX :
Regards,
2024-04-22 11:20 AM
Hi Gaetan, I've done even more tests to answer you, so now consider this situation:
1) Full black background (RGB565): no problems, it works both using internal memory or external flash throught my BlockCopy function.
2) Black background with tranparency (any) (ARGB8888), as you mentioned:
This is my block copy function:
bool TouchGFXHAL::blockCopy(void* RESTRICT dest, const void* RESTRICT src, uint32_t numBytes)
{
if ((uint32_t)src >= 0x90000000 && (uint32_t)src < 0x94000000)
{
uint32_t dataOffset = (uint32_t)src - 0x90000000;
char file_name[] = "media";
uint32_t ret = fs_read_file(file_name, dataOffset, numBytes, ((uint8_t*)dest));
if(ret == numBytes)
return true;
else{
memset((uint8_t*)dest, 0, numBytes);
return false;
}
}
else
{
return TouchGFXGeneratedHAL::blockCopy(dest, src, numBytes);
}
}
This is my Designer configuration:
This is x-cube-touchgfx configuration in STM32CubeMX :
This is the image section:
The memory details:
The HardFault error:
Thanks again for your support