Weird behavior when adding a new section to QSPI

[Exit0815]

Hello,

I have a problem adding a new section to QSPI with the graphics stored on it.

I want to store some error-text tables in a new section of the QSPI flash.

For that i shrinked the 64MB QSPI and added a new section in the linker script.

QUADSPI (r)    : ORIGIN = 0x90000000, LENGTH = 64M-20M
EXTERROR (r)	 : ORIGIN = 0x92800000, LENGTH = 20M

Then i created the section:

ExtErrorsSection :
	{
		*(ExtErrorsSection ExtErrorsSection.*)
		*(.gnu.linkonce.r.*)
        . = ALIGN(0x4);
	} >EXTERROR

The error text file looks like that:

const ErrorTexts __attribute__((__section__("ExtErrorsSection"))) SensorXYZ[] = {
{0x1234, "Value1 out of range"},
{0x1235, "Value2 out of range"},
{0x1236, "Value3 out of range"},
{0x1237, "Value4 out of range"}
};

 At runtime i decide which type of sensor it is and copy the table.

After building the code i can see at the Build Analyzer (i am using STM32CubeIDE) that the Memory Region "EXTERROR"  is filled with the table and at the Details i can see that the storing position at QSPI is "0x92800000".

But it seems that it will overwrite some graphics. Some graphics stored in QUADSPI region looks distortet.

As soon as i do not store data in "EXTERROR" everything works and the graphics looks good.

What is the best way to go on here to find out what the problem is?

Thank you very much.

[Exit0815]

The problem is not solved, but i think it will not work like i want.

Because the QSPI is in memory mapped mode for touchgfx, it is not possible to read when touchgfx is running.

For now i will stop with this way and try to create error texts in touchgfx designer. I will open another question regarding searching (strcmp) in specific text-groups. I hope there is a way to search in texts (language does not matter).

[Tesla DeLorean]

44MB is 0x2C00000, 40MB is 0x2800000, 64 MB is 0x4000000

Partition the memory appropriately. Perhaps specify the byte count. Check the .MAP file to ensure there's no overlap, or confusion.

On the App side checksum or crc the content of the different regions/blobs of code/data and explicitly check them once the memory is up, so you can confirm what the STM32 sees on it's side is the same as that built on the PC

[FBL]

Hello @Exit0815,

Are you sure you can not read in memory mapped mode?

[Exit0815]

Hello,

@Tesla DeLorean @FBL  thank you very much for your answers.

Maybe i was wrong, i thought you cannot read from QSPI in memory mapped mode, just touchgfx can. I do not want to write, the "tables" are compiled and stored in qspi, i just want to read them.

Let me try to explain a bit more detailed without any mistakes.
The QSPI is split into several parts.

REGION1 (r)	 	: ORIGIN = 0x90000000, LENGTH = 2M
REGION2 (r)    		: ORIGIN = 0x90200000, LENGTH = 2M
QUADSPI (r)    		: ORIGIN = 0x90400000, LENGTH = 64M-20M
EXTERROR (r)	 	: ORIGIN = 0x93000000, LENGTH = 16M

The section (i insert it after "TextFlashSection" from touchgfx in the LD):

ExtErrorsSection :
	{
		*(ExtErrorsSection ExtErrorsSection.*)
		*(.gnu.linkonce.r.*)
       . = ALIGN(0x4);
	} >EXTERROR

Then the program. I did a new simple test:

typedef struct _ErrorCodes {
    int ID;
    char RESULTNAME[56];
} ErrorCodes;

ErrorCodes Errors[400];
int maxErrorsRows;

const ErrorCodes __attribute__((__section__("ExtErrorsSection"))) SENSOR1[] = {
		{	0x1234,	"ERROR 1 ERROR 1 ERROR 1 ERROR 1 ERROR 1 ERROR 1   "},
		{	0x1235,	"ERROR 2 ERROR 2 ERROR 2 ERROR 2 ERROR 2 ERROR 2   "},
		{	0x1236,	"ERROR 3 ERROR 3 ERROR 3 ERROR 3 ERROR 3 ERROR 3   "},
		{	0x1237,	"ERROR 4 ERROR 4 ERROR 4 ERROR 4 ERROR 4 ERROR 4   "},
		{	0x1238,	"ERROR 5 ERROR 5 ERROR 5 ERROR 5 ERROR 5 ERROR 5   "},
		{	0x1239,	"ERROR 6 ERROR 6 ERROR 6 ERROR 6 ERROR 6 ERROR 6   "},
		{	0x123A,	"ERROR 7 ERROR 7 ERROR 7 ERROR 7 ERROR 7 ERROR 7   "}
};

const ErrorCodes __attribute__((__section__("ExtErrorsSection"))) SENSOR2[] = {
		{	0x2234,	"ERROR 1 ERROR 1 ERROR 1 ERROR 1 ERROR 1 ERROR 1   "},
		{	0x2235,	"ERROR 2 ERROR 2 ERROR 2 ERROR 2 ERROR 2 ERROR 2   "},
		{	0x2236,	"ERROR 3 ERROR 3 ERROR 3 ERROR 3 ERROR 3 ERROR 3   "},
		{	0x2237,	"ERROR 4 ERROR 4 ERROR 4 ERROR 4 ERROR 4 ERROR 4   "},
		{	0x2238,	"ERROR 5 ERROR 5 ERROR 5 ERROR 5 ERROR 5 ERROR 5   "},
		{	0x2239,	"ERROR 6 ERROR 6 ERROR 6 ERROR 6 ERROR 6 ERROR 6   "},
		{	0x223A,	"ERROR 7 ERROR 7 ERROR 7 ERROR 7 ERROR 7 ERROR 7   "}
};

And when i try to read the SENSOR1 and copy it to "Errors", Errors is empty:

maxErrorsRows = sizeof(SENSOR1) / sizeof(SENSOR1[0]);
memcpy(Errors, SENSOR1, sizeof(SENSOR1));

At the debuger Live Expression i can see that "SENSOR1" is not filled. Screenshot attached.

The Section is filled, from what i can see at the Memory Details, and when i check with STM32CubeProgrammer i see that "0x93000000" is filled with the correct values. Screenshots attached.

When i store it in flash, without "__attribute__((__section__("ExtErrorsSection")))" it works. SENSOR1 is filled with the correct values.

Am i doing something wrong?

Thank you.

[FBL]

Hello @Exit0815 

Could you specify which STM32 product you are using? Which System Clock frequency are you using? QUAD clock frequency? Perhaps read operations are not executed at the same speed. In debug mode, reads are at full speed.

Disable debug optimizations. Check map file to make sure of the contents being stored correctly.

[Exit0815]

Hello @FBL 

I have some discovery boards here, i tested with them. No problems.

My custom board use a STM32F779AIY

I also created a new project without any other "options" activated. Still the same problem.

When i change to store it on QSPI it works.

I can also see it in debug mode with debug optimizations.

Is it possible that there is a problem reading the data from "the end" of the QSPI?

So, actual status is, it works when i put the section to QSPI, where also touchgfx stuff is stored.

The reason i wanted to store it in a defined place is that i do not need to always update the full QSPI, these tables will not change, but i can live with that for now.

Graphics seems to be ok now, i have to check when i add all texts, if the problem is still "solved".

Thank you.