Skip to main content
ranran
Senior
September 22, 2019
Question

FMC accessed in 32-bit, but CS asserted for twice long (64-bits)

  • September 22, 2019
  • 3 replies
  • 1459 views

Hello,

We access FMC PSRAM in 32-bits.

We noticed that although the access was expected to be in 32-bits (using HAL_SRAM_Read_32b) , CS signal is actually asserted for long of 64-bits!

Is there anything which can explain why the CS is twice the time of the expected access ?

This is the initialization of this interface of bank #3.

As you can see access is also using no wait signal:

{
 FMC_NORSRAM_TimingTypeDef Timing;
 g_hfpga.Instance = FMC_NORSRAM_DEVICE;
 g_hfpga.Extended = FMC_NORSRAM_EXTENDED_DEVICE;
 /* g_hfpga.Init , page 821 in reference */
 g_hfpga.Init.NSBank = FMC_NORSRAM_BANK2;
 g_hfpga.Init.DataAddressMux = FMC_DATA_ADDRESS_MUX_DISABLE;
 g_hfpga.Init.MemoryType = FMC_MEMORY_TYPE_PSRAM;
 g_hfpga.Init.MemoryDataWidth = FMC_NORSRAM_MEM_BUS_WIDTH_16; 
 g_hfpga.Init.BurstAccessMode = FMC_BURST_ACCESS_MODE_ENABLE; //This bit enables/disables synchronous accesses during read operations
 g_hfpga.Init.WaitSignalPolarity = FMC_WAIT_SIGNAL_POLARITY_LOW;
 g_hfpga.Init.WaitSignalActive = FMC_WAIT_TIMING_DURING_WS; 
 g_hfpga.Init.WriteOperation = FMC_WRITE_OPERATION_ENABLE;
 g_hfpga.Init.WaitSignal = FMC_WAIT_SIGNAL_ENABLE; 
 g_hfpga.Init.ExtendedMode = FMC_EXTENDED_MODE_DISABLE; 
 g_hfpga.Init.AsynchronousWait = FMC_ASYNCHRONOUS_WAIT_ENABLE; 
 g_hfpga.Init.WriteBurst = FMC_WRITE_BURST_ENABLE; //<-- this enables synchronous mode
 g_hfpga.Init.ContinuousClock = FMC_CONTINUOUS_CLOCK_SYNC_ASYNC; bank1.ContinuousClock
 g_hfpga.Init.WriteFifo = FMC_WRITE_FIFO_ENABLE;
 g_hfpga.Init.PageSize = FMC_PAGE_SIZE_NONE;
 Timing.AddressSetupTime = 7;
 Timing.AddressHoldTime = 7; 
 Timing.DataSetupTime = 50;
 Timing.BusTurnAroundDuration = 4;
 Timing.CLKDivision = 4; //~200Mhz is clock source
 Timing.DataLatency = 4; 
 Timing.AccessMode = FMC_ACCESS_MODE_A; 
...
 
}

Read access timing diagram:

0690X00000ARTnrQAH.jpg

Thank you,

ran

This topic has been closed for replies.

3 replies

Tesla DeLorean
Guru
September 22, 2019

The bus is 16 bits wide and you're doing a 32 bit access?​

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
ranran
ranranAuthor
Senior
September 22, 2019

mhhh , yes.

So, that's seems like a big error....

waclawek.jan
Super User
September 22, 2019
ranran
ranranAuthor
Senior
September 22, 2019

Right, sorry.

Yes, it is stm32h743.

What is the link ? Is it answering this issue ?

Thanks

Tesla DeLorean
Guru
September 22, 2019

You present information through a key-hole making the complete context hard to understand or replicate properly.

The cited thread indicates you need to watch the MPU configuration so behaviour of the caching, write-buffering, etc the core is using don't cloud the interaction on the external bus.

The poster(s) there are trying to use simplistic memory-mapped hardware, where write-thru occurs immediately and in-order.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
ranran
ranranAuthor
Senior
September 24, 2019

Hi Clive,

You previously said that the bus is 16 bits wide

MemoryDataWidth = FMC_NORSRAM_MEM_BUS_WIDTH_16;

, and the access is 32 bit access

HAL_SRAM_Read_32b

Do you mean that it is illegal ?

Thank you!