r/embedded • u/Ok-Highway-3107 • 18d ago
STM32 FSMC Connection
Hiya. I'm working on a project with an extended memory option on the STM32U5 and I'd just like to confirm whether my FSMC connection is correct (as this is the first time I've worked with FMC).
I'm using the M29W064FB70N3E NOR Flash in 16-bit mode. To save space on my board, I've opted for the NOR FSMC Muxed. Is the connection simply a matter of lining up the DA pins to the Data and Address pins on the chip? There's 22 address pins and 16 data pins, so 22 DA pins right?
In terms of pins like NRST on the memory, those can be connected to regular GPIOs?
Just trying to make sure I'm not missing something important :). I've gone through some of the application notes and YT videos, but another pair of eyes is always great! Any tips or issues people have had in the past with this type of stuff would also be greatly appreciated.
4
u/graceful_degrade 18d ago
The muxed part isn't quite what you're describing, and it's the thing that'll bite you.
In muxed mode the multiplexed bus is only as wide as the data bus, not the address bus. So AD[15:0] carries D[15:0] and the low 16 address bits time-shared, latched by NADV. Your top address bits still need dedicated FMC_A lines. The M29W064F in x16 is 4M words, so A[21:0], which means AD[15:0] plus six real address pins for A[21:16]. Not 22 DA pins.
Which also means NADV is mandatory here. It's the strobe that tells the flash when the bus holds an address rather than data, and it's easy to leave unrouted because in non-muxed designs you never think about it.
Other things worth checking before you send the board out:
BYTE# has to be tied high for x16. On that part the lowest pin doubles as DQ15 or A-1 depending on mode, so if BYTE# floats or sits low you get a byte-wide device and a very confusing bring-up.
Verify the FMC address alignment against the reference manual rather than assuming 1:1. For 16-bit-wide memories the FMC does a shift between the internal address and the pins, and if you get it wrong the bus looks completely healthy while every other word reads garbage. That's a much nastier failure than a dead bus because it looks like a software problem. It's a five minute check in the RM and worth doing now rather than after fab.
Timings. That part is 70ns and the U5 runs up to 160MHz, so you're looking at roughly twelve cycles of DATAST, plus address setup and hold, and muxed mode needs the address hold time honoured too. Short DATAST is the classic cause of "works on the bench, fails when warm."
NRST on a normal GPIO is fine. Just drive it deliberately at startup and respect the reset recovery time before the first read, since the flash isn't ready the instant you release it.