cancel
Showing results for 
Search instead for 
Did you mean: 

memory with long write recovery time with FSMC of STM32F407IG

skirn9
Associate II
Posted on November 09, 2012 at 14:35

Hello,

I want to use a Everspin MRAM

MR256A08BCMA35

with the STM32F407IG.

This memory needs a stable address after write or chip enable goes high for at least 12 ns.

My STM and the FSMC are running with a HCLK of 168 MHz = 1 / 5,95 ns, so it holds the address stable after write enable goes high for 1 HCLK = 5,95 ns.

Is there any way to hold the address stable after write access for longer than 1 HCLK cycle.

The only way I found was to slow down HCLK, but this is no solution, because the CPU also gets slower.

Edit:

Could the Bus Turn Around Duration in register FSMC_BTR be a possibility?

The ref. manual says:

''These bits are written by software to add a delay at the end of a write/read transaction. This delay allows to match the minimum time between consecutive transactions (tEHEL from NEx high to NEx low) and the maximum time needed by the memory to free the data bus after a read access (tEHQZ)''

But there is no timing diagram or any further edescription, so I do not know, if the address is held until NEx goes low again.

Also the durations tEHEL and tEHQZ could not be found anywhere else in the ref. manual or the datasheet.
8 REPLIES 8
Posted on November 12, 2012 at 15:19

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6c6&d=%2Fa%2F0X0000000brp%2FQAJ_yDpzknQNKvqQ9BVR4ngfGedDGSZCoZSxcCGGwjg&asPdf=false
skirn9
Associate II
Posted on November 14, 2012 at 15:52

Hi Jan,

thanks for your help.

I will do some measurements when i got my hardware to see the behaviour of the FSMC when BUSTURN is changed.

But you are right, this is just an advice but no way to get a worst case timing setting for the memory, which will work under all conditions.

If I can't get more information about this from ST or if there is no way to hold the address stable for a longer period of time, I think that I will change the memory to a Cypress nvSRAM or a MRAM with SPI-interface.

Using extra latches to hold the address could be an alternative way, but it won't be easier and space is rare.
dev5
Associate
Posted on April 22, 2013 at 13:11

We have the same problem ! And I ask ST enigneers, why did you designed timings such as that phase have fixed 1 HCLK ??? We missed this insidious and despicable detail and now we are puzzled over possible workaround while not decrease performance dramatically !

dev5
Associate
Posted on April 23, 2013 at 14:17

I found more or less graceful workaround and want to share it.

I reconnected memory WR pin from FSMC_NWE to FSMC_NL(NADV) and configured memory type as NOR flash and mode 2 (see p.31.5.4/''Mode 2/B - NOR Flash'' of reference manual). Now it's possible to tweak requred hold time with DATAST ! It also solves similar address hold issue !

But it's not guaranteed that reading will work with any memory, because I'm not sure whether it's correct logic when WR strobe toggles high during active RD. Also you can't read in fsmc modes with OE toggling because you may get unwanted write access (and collision on databus) just before NOE goes low.

If reading isn't working in your case and performance isn't critical for read accesses then you may try possible workarounds:

1. dynamically reconfigure memory bank to SRAM type before read access and return back when reading complete

2. dynamically reconfigure FSMC_NL pin to GPIO and set it high before read access and also return back at end.

But be warned, that FSMC is not strictly synchronous with CPU. Previous write access may be incomplete at the moment when you prepare read access, so insert required delay before that (maybe it's not required in first case, but I'm not sure whether it's possible to change fsmc configuration on the fly). I didn't tried these workarounds because it's not required in my case.

I'm interfacing FSA506 LCD controller. Both writing and reading works perfectly for me. (STM32F207IG, HCLK =120 MHz, FSMC_BCRx = 0x00001048, FSMC_BTRx = 0x00000A0A, FSMC_BWTRx = 0x0FFFFFFF)

(Note: datasheet says that maximum time between NADV low-to-high strobe and data setup is Thclk+2 ns, so it may not work in case if memory data latching isn't slow enough.)

Posted on April 23, 2013 at 15:32

But be warned, that FSMC is not strictly synchronous with CPU.

The CPU core has Write Buffers, this may cause the write to be deferred, they will however be fenced by subsequent non-prefetch reads. ie memory access will occur in program order.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on April 24, 2013 at 11:23

But, data are not valid in the time when NADV is active... am I overlooking something?

JW

asmir
Associate
Posted on December 10, 2013 at 15:38

Karl Lipnen
Associate II

I found a solution to this problem for a similar processor STM32H743.

You need to use the FMC in the NAND mode, in this case it is possible to program the Hold Time.

Read more here: https://community.st.com/s/question/0D50X00009ZBxF3SAL/

It works successfully with my LCD (Toshiba controller JBT6K71-AS, tHOLD >= 15 ns ).