I have a use case for communicating with the SDRAM chip onboard the STM32G474E-EVAL1 board. Took a look at the board schematic https://www.st.com/resource/en/schematic_pack/mb1397-g474e-b04_schematic.pdf 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 https://www.st.com/resource/en/user_manual/um2514-evaluation-board-with-stm32g4xxqe-mcu-stmicroelectronics.pdf. , 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 (https://www.st.com/en/evaluation-tools/stm32g474e-eval.html#st_description_sec-nav-tab).
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?
