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.

29 REPLIES 29
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

GaetanGodart
ST Employee

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 :

GaetanGodart_0-1713528777295.png
 - screenshot of you x-cube-touchgfx configuration in STM32CubeMX :

GaetanGodart_1-1713528827979.png

 

Regards,

Gaetan Godart
Software engineer at ST (TouchGFX)

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:

  • Section int | extra section int => success
  • Section ext | extra section ext => hardfault
  • Section ext | extra section int=> hardfault

 

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:

Dadigno_0-1713809219577.png

This is x-cube-touchgfx configuration in STM32CubeMX :

Dadigno_1-1713809323182.png

This is the image section:

Dadigno_2-1713809405804.png

The memory details:

Dadigno_3-1713809475413.png

The HardFault error:

Dadigno_4-1713809665088.png

Thanks again for your support