FMC synchronous PSRAM - lost AHB transactions

[dstindl9]

Posted on October 30, 2017 at 14:09

Hello

I have FPGA with memory mapped peripheral what I would like to control from external STM32 MCU (STM32F767 ). I chose FMC peripheral in synchronous PSRAM mode because communication can be easily implemented in HDL wrapper. I was inexperienced in this stuff so firstly I just connected logic analyzers to FMC bus, made some configuration and did some write accesses 'into air'.

Unfortunately I have faced some problems what I don't understand.

My configuration for all PSRAM banks:

DataAddressMultiplex = off;

MemoryType = PSRAM; MemoryDataWidth = 16b; BurstAccessMode = on

WriteBurst = on;

Wait signal manage = off WriteOperation = on; ExtendedMode = None ContinuousClock = on WriteFifo = on; PageSize = none;

Timing:

AddressSetupTime = 15; AddressHoldTime = 15; DataSetupTime = 255; BusTurnAroundDuration = 15; CLKDivision = 2; DataLatency = 2; AccessMode = MODE_A;

First problem is that I'm loosing some AHB requests.

Example code

#define ADDR_PSRAM10x60000000 //PSRAM Bank 1
 
uint32_t wdata[8] = { 0x00010000, 0x00030002, 0x00050004, 0x00070006,
 0x00090008, 0x000B000A, 0x000D000C, 0x000F000E };
 uint32_t *pAddr = (uint32_t*) ADDR_PSRAM1;
for (i = 0; i < 8; ++i) {
 *pAddr++ = wdata[i];
 //myDelay();
}

I would expect that I will see 8 FMC write transactions but I saw only first one (sometimes two transactions). I was adding some sw delay (commented myDelay()) which solved the problem but I dont think it's good aproach.

First I had CLKDivision 16 so I though that CPU is too fast for FMC, so I switched division to 2 without noticeable effect.

Am I doing something wrong? I suppose FMC peripheral is for FLASH/RAM extension of MCU memory so there should be no problem. Is there some bit where I can check that FMC transactions is done? In reference manual there is information about AHB error flag but it is not useful for me.

Second problem is OCCASIONAL '

leakage

' in FMC transaction from following AHB data 'stream'. Please see attached pictures (1.png - 6.png). Pictures are screenshots of FMC entries from logic analyzer (see code above).

You can see values of D0-D7, A0-A4, NE1, NADV a CLK signals in FMC transactions. NE1 is basically same as NWE signal. Cursor 'C1.2' points at rising edge of clock where low 16b data from 32b value is written. Following rising edge should be remaining high 16b part.

After that NWE/NEx signal should be deasserted acording to reference datasheet but not in my case. You can see in first two pictures (1.png, 2.png) that two 32b AHB transactions were done in one FMC write. Sometimes I observed 3x32b in one FMC operation. Remaining FMC entries are ok from my point of view - values from 0x00090008 to 0x000F000E are written correctly.

This problem doesn't happen when write FIFO is disabled, but I don't know why...I have found nothing about it in reference manual.

Can someone please help me?

Regards

Daniel

#psram #ahb #fmc

[waclawek.jan]

Posted on October 31, 2017 at 14:34

There's cache on the AXIM interface of processor, and then there's a write FIFO on FMC itself.

The former is manipulated through MPU, see AN4839.

For the latter,

The Write FIFO can be disabled by setting the WFDIS bit in the FMC_BCR1 register.

JW

[dstindl9]

Posted on October 31, 2017 at 14:38

FIFO is disabled. It fixed problem with '

leakage' as i wrote in question.

I tried disabling cache (CMSIS cache functions) before - without a effect.

[dstindl9]

Posted on October 31, 2017 at 16:20

Well...I tried asynchronous PSRAM mode, then NOR FLash asynchronous. Still same problem with missing FMC transactions.

[waclawek.jan]

Posted on October 31, 2017 at 17:07

That's humm.

Are you running at maximum SYSCLK? If yes, try lowering it, maybe drastically, just for the trial.

I assume you have switched off the cache - read back the MPU registers to verify.

JW

[dstindl9]

Posted on November 01, 2017 at 16:58

Well...a progress.

Configuration of MPU helps a lot (see

http://www.keil.com/support/docs/3777.htm

  and examples in CubeMX repository).

I have only problem with repeated write at the same address. Other operations work.

//volatile is necessary

volatile uint32_t *pAddr = (volatile uint32_t*) ADDR_PSRAM1;

int i;

uint32_t wdata[8] = { 0x00010000, 0x00030002, 0x00050004, 0x00070006,

            0x00090008, 0x000B000A, 0x000D000C, 0x000F000E };

/* Write operations */

//works only when you put a delay

for (i = 0; i < 8; ++i) {

    *pAddr = wdata[i];    //myDelay();}

//works

for (i = 0; i < 8; ++i) {    *pAddr++ = wdata[i];}

/* Read operations */

//worksfor (i = 0; i < 8; ++i) {    wdata[i] = *pAddr;}

//works

for (i = 0; i < 8; ++i) {    wdata[i] =  *pAddr++;}

[Ivaylo Ilchev]

Posted on June 11, 2018 at 22:44

Hi All,

I spent a lot of time with the same problem last summer: National Instruments PXI case with Flex RIO FPGA, communicating with the MCU STM32F746 via two queues thru FMC in PSRAM mode, multiplexed DATA/ADDR lines 8 bits, worst case timings set: 16, 16, 255. Sometimes bytes from the input queue were lost. The problem was with the interrupts - the transaction to the FMC is repeated if interrupt hit at the time of reading, but the queue deletes the byte and serve next. Enclosing readings with enter/exit_critical_section helps to clear the problem.

[waclawek.jan]

Posted on June 12, 2018 at 09:17

Ivaylo,

To reduce interrupt latency, the ARM-v6 processors (including Cortex-M3/M4/M7) implement interruptible multi-cycle instructions, including multi-cycle loads/stores (LPM/STM). These may be implemented either  as continuable or replayable. Now the public documentation is not entirely clear about this, but it appears that while Cortex-M3/M4 implements the LPM/STM as continuable, it implements a more complex mechanism in Cortex-M7, where these instructions in memory areas tagged as Normal are replayed upon interrupt, in Device and Strongly-ordered areas they are continued.

I know it was some time ago and it would require non-negligible amount of work, but could you please return to the problem, allow it to occur again, and then set the MMU so that the FMC area in question is marked Device or Strong-ordered?

Thanks,

Jan