cancel
Showing results for 
Search instead for 
Did you mean: 

64Mbit accessible

idrissmc
Associate III

Hi everyone,

why they mentioned (64Mbit accessible only) in QSPI?

1 ACCEPTED SOLUTION

Accepted Solutions

It says it for the SDRAM, not the QSPI

Why, because they used a 32-bit wide SDRAM due to price, availability or physical size/package, but they only have 16-bit of the data bits wired up, due to pin availability on the STM32 side. Consequently half the available capacity is lost.

The 32-bit wide SDRAM may be significantly cheaper because it's used in 100M quantities in some phone, tablet, or PC application.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

6 REPLIES 6

It says it for the SDRAM, not the QSPI

Why, because they used a 32-bit wide SDRAM due to price, availability or physical size/package, but they only have 16-bit of the data bits wired up, due to pin availability on the STM32 side. Consequently half the available capacity is lost.

The 32-bit wide SDRAM may be significantly cheaper because it's used in 100M quantities in some phone, tablet, or PC application.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
idrissmc
Associate III

Oh lol I’m not good today, I thought for QSPI, sorry, then if it’s only the half is available! Supposed if I do, let say, a considerable application on this board, it won’t work? For example it might tell me SDRAM overflowed or something like that?

If you tell the linker you have 8MB (64Mbit) of SDRAM, it will tell you if/when you exceed the capacity.

If your application needs more SDRAM than that, you'd need to consider a different board to do the proof-of-concept on.

The SDRAM should be more than sufficient to sustain the screen buffer(s) for the 480x272 display.

I would generally avoid the SDRAM for code or stack as it is slower, and contended, the cache may hide most of this on the F7

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

>> I would generally avoid the SDRAM for code or stack as it is slower, and contended, the cache may hide most of this on the F7.

its very interesting this sentence, but I can’t understand it, can you explain me what do you mean please?

The external memory accesses slow, so fetching and writing have significantly more latency.

Typically to operate at full/optimal speeds you want to put critical data in more tightly coupled memory (TCM), the stuff that can be accessed within the current cycle, or one cycle.

All your code is likely dependent on the stack, for passing parameters, or holding auto/local variables. You should use the internal SRAM or DTCMRAM for such things. The DTCMRAM is fast, and not cached, allowing the cache to focus on slower memory a bus, or two, away from the core.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Thank you very interesting :smiling_face_with_smiling_eyes: