proper use of PSRAM

[WMXZ]

I wanted to know what the proper use of PSRAM is in relation to data cache

I use PSRAM as huge databuffer in my recorder
for this I plan to use the following (simple) Queue object where buffer may be initializes using EXTMEM

class Data
{
    public:
        Data(uint32_t * buffer) { data_buffer=buffer; front_=rear_=0;}

        uint16_t push(uint32_t * src)
        { 
            uint16_t f =front_ + 1;
            if(f >= MAXBUF) f=0;
            if(f == rear_) return 0;

            uint32_t *ptr= data_buffer+f*NBUF_ACQ;
            memcpy(ptr,src,NBUF_ACQ*4);
            #if defined(USE_EXT_MEM)
               	arm_dcache_flush_delete((void *)ptr,NBUF_ACQ*4);
            #endif
            front_ = f;
            return 1;
        }

        uint16_t pull(uint32_t * dst, uint32_t ndbl)
        {   
            uint16_t r = (rear_/ndbl) ;
            if(r == (front_/ndbl)) return 0;

            uint32_t *ptr= data_buffer + r*ndbl*NBUF_ACQ;
            #if defined(USE_EXT_MEM)
               	arm_dcache_delete((void *)ptr,NBUF_ACQ*4);
            #endif
            memcpy(dst,ptr,ndbl*NBUF_ACQ*4);
            if(++r >= (MAXBUF/ndbl)) r=0;
            rear_ = r*ndbl;
            return 1;
        }
        uint16_t getCount () { if(front_ >= rear_) return front_ - rear_; return front_+ MAXBUF -rear_; }

private:    
    uint16_t front_, rear_;
    uint32_t *data_buffer;

};

So there are four questions
- are the arm_dcache* functions really necessary (program seemed to work without them).
- are changing the write/read addresses not sufficient to invalidate the cache?
- if not, is it correct to call 'arm_dcache_flush_delete' after writing to EXTMEM and 'arm_dcache_delete' before read?
- is 'arm_dcache_delete' really needed?

 

[KurtE]

@WMXZ - A lot of this "depends". Also others probably can give a much more detailed answer.

As I am pretty sure you already know, the arm_dcache stuff is mainly only needed when you are using hardware like DMA operations to or from that memory, as some of these operations go directly to the hardware memory and bypass the cache. So for example if you are writing into that memory and then try to do a DMA operation out of that range of memory, you may get some new and some old data on the DMA operation.

Likewise if you do DMA into that range of memory and then do reads, if that range of stuff is in the cache it may use the previously cached values...

But if you are simply doing a bunch of memcpy in and out of that range of memory, than they probably are not needed.

Not sure if that answers any of your questions.

 

[Frank B]

In short: No DMA: Don't worry about the cache. Ignore its existance. You don't need the functions.
The cache is smart enough to know when its contents need to be written to the RAM.
It is pretty smart anyway.For example it is able to detect a memory fill ("memset" for example) and does not cache this data. It then keeps its lines for more valuable data.

With DMA: The cache hides the real memory contents - DMA does not know that there might be newer data in the cache.
And vice versa. The cache does not know that the memory had an update. So, in this case, you need the functions.

 

[WMXZ]

Kurt, Frank,
thanks for answer.
Yes, in my DMA isr I'm using the arm_cache functions.

I was only confused by the psram_memtest program that uses arm_dcache functions between write and read.
Anyhow, my program worked without these functions, so I'm happy to remove them again from direct access of EXTMEM memories

 

[defragster]

psram_memtest likely uses the cache control just to insure the integrity of the test. That the data is really backed by the device and not just 'emulated' by the cache - and perhaps actually included the total access time not just filling/using the cache.

The only other time cache flush is critical - is when writes are made and then a restart is intended - FrankB"s hardfault code does that to RAM2 where it stores fault info before restarting and that memory contents are held over for the next start.