GFX use of internal RAM?

[VO_it]

I noticed that areas of internal SRAM appear to be used by GFX. I inferred this from a project I am doing with an H745 dual core micro; I set aside a small amount of SRAM4 to be shared between the cores, and I can watch on the debugger as portions of that memory space can be updated or not, depending on whether I have interacted with the LCD. This suggests that GFX is helping itself to the SRAM, and I need to know how we can declare an amount of internal RAM off-limits (or, are there documented regions of SRAM that are safe to use when running GFX?). The DISCO board uses external SDRAM, by the way. 

 

Thanks for any insights someone might be able to offer.

[mƎALLEm]

Hello,

The description is not clear to me. 

Especially this statement "This suggests that GFX is helping itself to the SRAM, and I need to know how we can declare an amount of internal RAM off-limits "

May be you need to give more details of what you're planning to do.

And what's the problem with the external SDRAM?

[VO_it]

Certainly, and thank you for the prompt response.

I am using an H745 dual core micro, and I declared a small amount of memory in SRAM4 to be used for the M4 to write and the M7 to read as necessary, triggered by a hardware semaphore. Here is the declaration for the record:

volatile sharedDataType_t* const ptrSharedData = (sharedDataType_t*) 0x30000000

In other words, I used the common method of declaring a pointer to a memory address, put it in both the M4 and M7 spaces, and then referenced this in each program file. This worked flawlessly in a small test program I ran just to see if I had the method down.

In my actual project running GFX, I kept noticing that the memory area would sometimes be updated when I wrote new data to it, and sometimes not, even when I used a clock-like test loop that just incremented a value for debugging purposes. Then, almost by accident, I touched a button on my LCD and the thing took off as intended, updating on each pass... I could fix and break that memory read just by going back and forth between the screens! That is when I suspected the GFX software was using the same SRAM area I had chosen. That is to be expected, I guess, but if so, then I need to know how reserve the ~2k bytes I need for my inter-core communication. I suspect this would be via a modification to the linker file, but that topic is not one I have mastered.

Does this make sense? Thank you again for your help.

 

[mƎALLEm]

If I understood well your issue, you are facing a SRAM region overlap between SRAM used by GFX and the Shared memory CM7/CM4. So why you don't separate the SRAM and use another instance for example SRAM1, 2 or 3? 

[VO_it]

Thanks for the input, SofLit. It occurred to me over the weekend that what I was seeing was likely the result of a cache not being flushed, and when I interacted with the display, GFX was issuing a refresh command somewhere, causing the numbers to finally update for a few cycles. I went into the Cube's memory protection unit setup and reserved a few kB of memory for both cores, making it sharable and non-cacheable, and the problem is solved.

I see that you are an ST employee; let me kindly suggest that you pass this along as a topic for a short APP Note in the hope that it helps others with similar applications. All of this information was already out there in bits and pieces, and I had read it many times, but never connected the dots until after many hours of struggle and thought.