stm32f7 NOR flash ,

[simonsimon9172]

Posted on January 16, 2017 at 16:43

A real simple questoin here, 

I'm  a hardware guy...

sorry.

Looking at the stm32F7 data sheets, and using the fmc in NOR flash mode. 

From the software perspective, would you have a lump of code that does the sequence of instructions to do the write to the NOR ?

I have a off the wall idea to use the NOR interface to access to an FPGA  If I can have the NOR flash bus timings, without the overhead of the write instructions and poling , then that would be faster / lower latency than a SRAM interface due to the lack of synchronization needed.

[waclawek.jan]

Posted on January 16, 2017 at 16:58

What synchronisation are you talking about?

[simonsimon9172]

Posted on January 16, 2017 at 17:21

Hi Jan

Meta stability .its a hardware problem we have to overcome.

The FPGA will have to accept the signals from the STM32F7, such as NOE and NWE, 

    and sample them on its internal clock so they can drive the state machines in the fpga.

If the FPGA clock is fixed phae and frequency with relation to the STM32F7 clock that drives the NOE / NWE signals, then we can use a single register synchronize in the FPGA. If the STM32F7 clock is asynchronous or of unknown phase to the FPAG clock, we have to use a three register meta-stable hardener in  the FPGA to get reliable performance. 

This meta stability hardening necessitates a lengthened  STM32F7 bus cycle, 

Which is why things like NOR rams have a clock form the CPU, so their state machine can be synchronous and no need for the meta stability hardening registers. 

But a little knowledge is dangerous. To write to a NOR flash, one has a convoluted cycle , involving setting up the NOR flash command , and waiting for the flash to finish its write, which is slow. If the convoluted part of the cycle is handled in the software, and I don't need that in the FPGA, then I could use a NOR flash cycle to make a synchronous interface to eh FPGA, and improve the cycle time. Every ns counts in this application.

[S.Ma]

Posted on January 16, 2017 at 18:16

In case it could be useful my 2 cents input: MCO pin enables internal clock to be output to gpio with optional prescaler. If the bandwidth is not critical, a simple 8 bit 8080/6800 parallel interface with Rd/W and C/D (Command Data) is a classical interface to display controllers which could be easy to.mimic for fpga with limited wire control. Otherwise, no experience beyond this for external interface to fpga.

[waclawek.jan]

Posted on January 16, 2017 at 18:19

What you are probably looking for are the synchronous read/write modes of the FSMC/FMC SRAM/NOR module, enabled by FSMC_BCRx.CBURSTRW and FSMC_BCRx.BURSTEN respectively. I am afraid the resulting clock is non-continuous, which probably is not what you are looking for. It should be somehow synchronous to the internal system clock, though, so some sort of synchronicity could by achieved against a clock derived from system clock output onto MCO, taking into account possible phase shifts; but this is something you ought to investigate further.

One warning, the FSMC/FMC chapters are a mess.

JW

[waclawek.jan]

Posted on January 16, 2017 at 18:04

NOR FLASH are not inherently synchronous. NAND FLASH customarily are.

JW

[Tesla DeLorean]

Posted on January 16, 2017 at 18:10

The NOR writing sequences would all have to be handled in software. The mode of the F(S)MC just controls the sequencing of the signals on the bus, you'd then have the software do a whole sequence of reads/writes. I don't think the SRAM vs NOR mode makes a significant difference, but all the clocking is done synchronous to the processors AHB clock.

The NAND mode used to have a NREADY signal so you could stuff wait states at the processor.

Could you use a common clock source? Speced to take 4-26MHz, other STM32's take close to 50 MHz as I recall.

Can the part of the FPGA connecting to the processor live in a different clock domain from the rest of FPGA?

Not sure I've encountered many clocked NOR devices?

Have you thought of using the QSPI interface, or SDIO? The former being synchronous, and mappable into memory, though can't say I've looked at the write mechanics there.

[Tesla DeLorean]

Posted on January 16, 2017 at 19:08

Most ASIC I've dealt with have an asynchronous CPU interface so you can get the simple 8080/6800 type bus interface. Where those internal registers need to get into another clock domain you have a resynchronizer. The GPIO/TIM pins on the STM32 have a resynchronizer to bring in external signals.

For FPGA to CPU, take a look at the DCMI, a synchronous parallel input bus clocking up to 54 MHz as I recall. This gets buffered/synchronized into the STM32's clock domain.

For systems with disparate clocks, there are these FIFO type devices 

http://www.averlogic.com/AL422B.asp

 

[simonsimon9172]

Posted on January 17, 2017 at 09:45

Thank you all for the replies,  

General, its the speed / latency we are trying to improve, and the synchronizes are needed for the current sram based asynchronous interface, hence why looking at can we get a synchronizing clock from the cpu. Also why we don't want to add wait states.

Clive. The DCMI,it is an interesting thought, I seem to remember its a frame based interface, needing Hsync and Vsync, but its no more than a passing memory. I will take a look at it.  QSPI have looked at, its a streaming interface, and has low latency.  Your info on the NOR protocol being done in software is great news. It means we could NOT use the protocol,  and use the synchronous NOR interface and just use it as a address / data bus, but synchronous to / from the FPGA.

Jan, a synchronous mode of the FMC would be good. If I could get 32 bit data, it only seems to support 16 bits. I read about the modes of the FMC, for instant, bit 20 of FMC_BCR1..4 registers, is continuous clock enable, This would seem to do what we want , but no specification on the clock phase / timins to the signals. And I can not seem to be able to set it in the CUBE software, so I am wondering is it possible with SRAM and 32 bit data !

One other thought, more for ST I guess, 

The STM32F7 looks good, but what I'm finding as a new bee to the STM32 range, is there is almost an inherent assumption that you have used previous generations of STM parts , with ARM M0 and M4 come to mind. For those of us new to STM though 40 plus tears of designing Asics, its interesting.

One example, is it an FMC or an FSMC ? 

Many thanks guys for reading and your input, 

[waclawek.jan]

Posted on January 17, 2017 at 11:08

One example, is it an FMC or an FSMC ? 

FSMC is the older version of the external memories interface in STM32; it's basically the same as FMC except it does not have the SDRAM part.

If I could get 32 bit data, it only seems to support 16 bits.

I don't see why would that be so, see FMC_BCRx.MWID

bit 20 of FMC_BCR1..4 registers, is continuous clock enable

I wasn't aware of this feature, it's not present in the older FSMC.

no specification on the clock phase / timins to the signals

See the datasheet. The timings are given for one particular setting of the registers, but you can get the idea.

And I can not seem to be able to set it in the CUBE software

I wouldn't rely on CubeMX (careful, Cube (or CubeL4, CubeF7 etc. as its incarnations for the various families) is the name of the embedded library (or in ST's parlance, 'firmware') which is needed for the code generated by CubeMX, the PC program).

The STM32F7 looks good

I recommend you to get a

http://www.st.com/en/evaluation-tools/nucleo-f429zi.html

, set up a basic software development environment and experiment. Later you can then get one of the F7 Nucleo-144 and migrate.

JW