cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 with SDRAM: How to connect unused DQMs?

Lars Beiderbecke
Senior III
Posted on February 12, 2018 at 19:29

I'm about to use a STM32F7 MCU with some x16 SDRAM. Since I don't use byte or unaligned accesses, I disabled the NBL pins, which should otherwise be connected to DQMH/L at the SDRAM.

But if I don't use those signals, how should DQMH/L be connected? I've checked several SDRAM data sheets, but this case is never mentioned. One manual seems to suggest to connect both to GND, another site says to connect them to the NOR or WE and CAS.

So, which way is it?

#sdram #fmc
1 ACCEPTED SOLUTION

Accepted Solutions
Posted on February 12, 2018 at 22:37

I was perhaps too hasty with that grounding those pins.

In a single-SDRAM system, there's one particular situation where the DQM signals are needed, namely where writes cut into a ongoing read burst - there, the data read from the SDRAM may collide with the first datum to be written.

Simpler SDRAM controllers, which attempt to translate traditional memory reads and writes as simply into SDRAM protocol as possible, are designed so, that they provide (column) address for every data written/read, thus they don't utilize the burst feature of the SDRAM. That means, that after the last read datum (i.e. in CAS-latency-cycle after the last READ command) the data bus goes to Hi-Z automatically; and as in such simplistic controllers from the system point of view all accesses would go into completion before another access would commence, writes won't be pipelined together with reads, there is never such a read-to-write collision on the bus.

I have read cursorily the FMC chapter when the 'F42x came out, as we planned a product making use of this back then; but in fact have never gotten to it, so my STM32-FMC-specific 'expertise' comes only from that reading. Now I remembered that the RM requires to set the SDRAM's mode register to burst=1, and the narrative also confirms that all accesses from the system are translated into single reads and writes; so I assumed this is the case of that simplistic SDRAM controller I described above. However, reading now I realized that there's a FIFO which appears to perform some read-ahead, which might perhaps result in the described read-to-write collision. (It appears that that read FIFO can be disabled by  clearing RBURST bit - I don't quite understand its impact on overall performance).

I could not find any description of read-to-write process, so there is no assumption on that. I don't even understand, whether read-to-write to the same (or active in other bank) row invokes precharge/activate commands or not.

I could also find no usable information on the exact behaviour of NBL pins.

So, please take my above 'you can ground DQMs' advice with a healthy pinch of salt - after all, the eventual failure is yours, so please make your own investigation. Connecting the NBL pins to DQMs is staying on the safe side.

JW

PS. I fail to see how the proposed NOR is supposed to operate, exactly.

View solution in original post

6 REPLIES 6
Posted on February 12, 2018 at 20:30

If the SDRAM is the sole device connected to FMC, you can ground them.

[EDIT] read my post below [/EDIT]

JW

Posted on February 12, 2018 at 21:03

Thanks!

Posted on February 12, 2018 at 21:04

Actually, just out of curiosity, if I have two SDRAMs, is it the NOR(WE, CAS) then?

Posted on February 12, 2018 at 22:37

I was perhaps too hasty with that grounding those pins.

In a single-SDRAM system, there's one particular situation where the DQM signals are needed, namely where writes cut into a ongoing read burst - there, the data read from the SDRAM may collide with the first datum to be written.

Simpler SDRAM controllers, which attempt to translate traditional memory reads and writes as simply into SDRAM protocol as possible, are designed so, that they provide (column) address for every data written/read, thus they don't utilize the burst feature of the SDRAM. That means, that after the last read datum (i.e. in CAS-latency-cycle after the last READ command) the data bus goes to Hi-Z automatically; and as in such simplistic controllers from the system point of view all accesses would go into completion before another access would commence, writes won't be pipelined together with reads, there is never such a read-to-write collision on the bus.

I have read cursorily the FMC chapter when the 'F42x came out, as we planned a product making use of this back then; but in fact have never gotten to it, so my STM32-FMC-specific 'expertise' comes only from that reading. Now I remembered that the RM requires to set the SDRAM's mode register to burst=1, and the narrative also confirms that all accesses from the system are translated into single reads and writes; so I assumed this is the case of that simplistic SDRAM controller I described above. However, reading now I realized that there's a FIFO which appears to perform some read-ahead, which might perhaps result in the described read-to-write collision. (It appears that that read FIFO can be disabled by  clearing RBURST bit - I don't quite understand its impact on overall performance).

I could not find any description of read-to-write process, so there is no assumption on that. I don't even understand, whether read-to-write to the same (or active in other bank) row invokes precharge/activate commands or not.

I could also find no usable information on the exact behaviour of NBL pins.

So, please take my above 'you can ground DQMs' advice with a healthy pinch of salt - after all, the eventual failure is yours, so please make your own investigation. Connecting the NBL pins to DQMs is staying on the safe side.

JW

PS. I fail to see how the proposed NOR is supposed to operate, exactly.

Posted on February 13, 2018 at 07:22

Thanks for the update!

I think I'll just use the NBL pins and connect them to DQM, even if I don't use byte access. Let the FMC figure things out. 🙂

AShch.2
Associate II

Could ST engineers please confirm if it's OK to ground 8-bit SDRAM DQM pin?