Showing results for 
Search instead for 
Did you mean: 

Interfacing With STM32G474E-EVAL1 SDRAM (IS61WV51216BLL-10MLI)


I have a use case for communicating with the SDRAM chip onboard the STM32G474E-EVAL1 board.  Took a look at the board schematic and an example project that came with the STM32 Cube IDE which should be located under this directory: C:\Users\your_username\STM32Cube\Repository\STM32Cube_FW_G4_V1.5.1\Projects\STM32G474E-EVAL\Examples\FMC\FMC_SRAM.

This code essentially sets up the relevant GPIO for alternate pin function 12, which gives us [A0:A18], [D0:D15], NE1, NWE, NOE, NBL0, and NBL1.  It then sets of the relevant FSMC registers for asynchronous 16-bit transfers.

The README document (attached) references the exact same SDRAM chip (IS61WV51216BLL), which I would expect, as the example is specifically geared towards the STM32G474E-EVAL board.  Part of me has a slight suspicion that some electrical change from the EVAL to the EVAL-1 board might be causing interference on one of more of the pins.  The reason for this suspicion is on page 24 of the user manual , which states "The dedicated motor control STM32G474E-EVAL1 board is supported for motor-control module application only".  I'm not exactly sure how to interpret this, as the EVAL-1 user guide talks about all of the other peripherals and how to use them, so might need to some more clarity on this.  If the EVAL-1 was truly only capable of performing the motor control function and nothing else, I wouldn't have thought STM would have discontinued the original STM32G474E-EVAL board (

When I took out an oscilloscope and sampled a few of the pins, I found that some of the address lines were not working and some of the data lines weren't either.


Channel 1 (yellow): connected to PF2 (A2)

Channel 2 (blue): connected to PD5 (NWE)

Channel 3 (red): connected to PF10 (A0)

Channel 4 (green): connected to PF7 (A1)

I understand the caveat here regarding the mapping of the address to the pins when we are set up for a 16-bit transfer, but even after taking that into account, there still seems to be an issue.


I've seen a similar anomaly on the data lines.  I expect to see traffic on D0 and D1, but I do not.  I do see traffic on D2, and a few other data pins, which tells me that at least something is working.


Channel 1 (yellow): connected to D2

Channel 2 (blue): connected to D0

Channel 3 (red): connected to D1

Channel 4 (green): connected an address line (for reference).  I forgot which one, but doesn't matter here.

I printed out the first 8 address and data values from the for loop in the example code.


So in summary, what I am trying to figure out is, are some of the FSMC pins on the STM32G474E-EVAL-1 pins routed to multiple places such it interferes with SDRAM communication, or is the problem elsewhere?