2019-09-22 01:02 AM
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:
Thank you,
ran
2019-09-22 04:44 AM
The bus is 16 bits wide and you're doing a 32 bit access?
2019-09-22 05:07 AM
You did not care to tell us the STM32 model you are using.
JW
2019-09-22 09:18 AM
Right, sorry.
Yes, it is stm32h743.
What is the link ? Is it answering this issue ?
Thanks
2019-09-22 09:19 AM
mhhh , yes.
So, that's seems like a big error....
2019-09-22 09:32 AM
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.
2019-09-23 11:57 PM
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!