32-bit vs 16-bit SDRAM performance for 1024x768 resolution display with STM32H750XBH6

[Geethat]

Split from this thread.

Thank you for your previous responses and guidance.

1. We are now planning to move to the STM32H750XBH6 (BGA package) with a 32-bit SDRAM (IS42S32400J-6TLSDRAM ) interface in our custom board design.
2. Our project uses a 12.1-inch display with a 1024x768 resolution and the RGB to LVDS transmitter ic  which is DS90C385AMTX_NOPB display ic  In our previous design with a 16-bit SDRAM, we observed display rendering and FPS issues, which affected performance. To overcome this, we are considering upgrading to a 32-bit SDRAM for improved rendering speed and smoother graphics performance.
3. Before proceeding further, we would like your confirmation on whether using a 32-bit SDRAM with the STM32H750XBH6 will actually improve the display rendering performance for our 1024x768 resolution.
4. If there is no significant improvement even with 32-bit SDRAM, then moving ahead with this design would not be worthwhile.

Please confirm this so that we can proceed further based on your feedback

[DmitryR]

Good day Geethat,

problems of using SDRAM lie often not in the area of bandwidth but in the area of delays. Dynamic memories need refreshing that, if done not properly, may lead to severe delays. If you calculate bandwidth needed for you display you will find out that 16-bit at 100MHz is enough with 50% reserve. FMC may run up to 200MHz so if you experience problems still I do not think that it is bandwidth.

And one more advice. Latest STM32H7 chips have LVDS transmitter inside. If you use it you will need to escape about five times less signals for a display from the MCU so that will make PCB routing much more simple.

With best regards,

Dmitry

[mƎALLEm]

Hello @Geethat 

This is a new question, you need to ask that in a separate thread.

Thank you for your understanding.

[Geethat]

Thank you very much DmitryR for your reply

As I am not from the firmware side, I didn’t fully understand the detailed points, but I do understand that bandwidth is not the main issue here. However, could you please explain a bit more about the delays related to dynamic memories and how improper refreshing might cause them? A more elaborate explanation would be very helpful for me to understand this better this will help me to analyze our hardware design and overall data flow better.

With best regards,
Geetha

[mƎALLEm]

Hello, 

[DmitryR]

Good day Geethat,

unlike static RAM that uses 6T-latches to store data dynamic memories use capacitors for that. But a capacitor loses charge on time so it needs to be refreshed. Refresh command takes about 60ns time (see datasheet) and should be provided 4096 times in every 64ms interval. Intellectual controllers find time between operations to issue these commands. Simple controllers just issue this command 4096 times on 64ms timer blocking all DRAM operations for a long time. Even if the controller issues refresh evenly, i.e. once per 15625ns, it may lead to problems. The problem here is that DRAM is not a really random access but it is organized in rows. To start reading row it should be "opened" that issues RAS latency (4-6 clocks + command), then read starts that issues CAS latency (2-3 clocks + command). After row is read it should be "precharged" (FMC does not support autoprecharge) that also takes several clocks. So if the stream that was requested from LTDC is broken by refresh command it makes long delay - row should be first closed ("precharged"), then refresh takes 60ns, then row should be opened again issuing RAS and CAS latencies. And LTDC has only 64-entry FIFO so the described case will very probably lead to a displaying artifact if you do not have good enough time reserve i.e. memory clock is much faster than LTDC clock.

Ah, one more thing. LTDC may operate two layers. In this case required bandwidth may be doubled (depends on pixel format in layers, may differ). Then, if LTDC issues reads so that they cannot be ordered in SDRAM rows that will insert additional delays switching from reading one row to another and then back. Intellectual DRAM controllers can reorder commands but I do not think that FMC can. If it is your case try at least to set up layer addressing so that they reside in different SDRAM banks and do not cross bank border - rows in different banks may be opened simultaneously.

With best regards,

Dmitry

[Geethat]

@mƎALLEm Thank you for sharing this image. Could you please let us know from which document this reference is taken? It would be very helpful for us to go through the complete section for better understanding.

[Geethat]

Hi @DmitryR 

Thank you very much for your detailed explanation earlier — it really helped us understand the DRAM refresh timing, LTDC bandwidth, and FMC behavior more clearly.

I have discussed your suggestions with my development team, and we implemented the below changes as guided, but the display performance remains unchanged.

Based on your guidance, we reviewed our SDRAM initialization and made the following changes.
For your reference, I’ve included both our previous configuration and the updated configuration below.

Previous Configuration:

hsdram1.Instance = FMC_SDRAM_DEVICE;
hsdram1.Init.SDBank             = FMC_SDRAM_BANK1;
hsdram1.Init.ColumnBitsNumber   = FMC_SDRAM_COLUMN_BITS_NUM_8;
hsdram1.Init.RowBitsNumber      = FMC_SDRAM_ROW_BITS_NUM_12;
hsdram1.Init.MemoryDataWidth    = FMC_SDRAM_MEM_BUS_WIDTH_16;
hsdram1.Init.InternalBankNumber = FMC_SDRAM_INTERN_BANKS_NUM_4;
hsdram1.Init.CASLatency         = FMC_SDRAM_CAS_LATENCY_3;
hsdram1.Init.WriteProtection    = FMC_SDRAM_WRITE_PROTECTION_DISABLE;
hsdram1.Init.SDClockPeriod      = FMC_SDRAM_CLOCK_PERIOD_2;
hsdram1.Init.ReadBurst          = FMC_SDRAM_RBURST_ENABLE;
hsdram1.Init.ReadPipeDelay      = FMC_SDRAM_RPIPE_DELAY_0;

/* SDRAM Timing */
SdramTiming.LoadToActiveDelay    = 2;
SdramTiming.ExitSelfRefreshDelay = 7;
SdramTiming.SelfRefreshTime      = 5;
SdramTiming.RowCycleDelay        = 7;
SdramTiming.WriteRecoveryTime    = 5;
SdramTiming.RPDelay              = 3;
SdramTiming.RCDDelay             = 3;

/* Refresh Counter */
#define REFRESH_COUNT ((uint32_t)0x050C) // (15.625 µs × 100 MHz) - 20 = 1542
#define IS42S32400J_TIMEOUT ((uint32_t)0xFFFF)

 Updated Configuration:

hsdram1.Instance = FMC_SDRAM_DEVICE;
hsdram1.Init.SDBank             = FMC_SDRAM_BANK1;
hsdram1.Init.ColumnBitsNumber   = FMC_SDRAM_COLUMN_BITS_NUM_8;
hsdram1.Init.RowBitsNumber      = FMC_SDRAM_ROW_BITS_NUM_12;
hsdram1.Init.MemoryDataWidth    = FMC_SDRAM_MEM_BUS_WIDTH_16;
hsdram1.Init.InternalBankNumber = FMC_SDRAM_INTERN_BANKS_NUM_4;
hsdram1.Init.CASLatency         = FMC_SDRAM_CAS_LATENCY_3;
hsdram1.Init.WriteProtection    = FMC_SDRAM_WRITE_PROTECTION_DISABLE;
hsdram1.Init.SDClockPeriod      = FMC_SDRAM_CLOCK_PERIOD_2;
hsdram1.Init.ReadBurst          = FMC_SDRAM_RBURST_ENABLE;
hsdram1.Init.ReadPipeDelay      = FMC_SDRAM_RPIPE_DELAY_0;

/* SDRAM Timing */
SdramTiming.LoadToActiveDelay    = 2;
SdramTiming.ExitSelfRefreshDelay = 8;
SdramTiming.SelfRefreshTime      = 5;
SdramTiming.RowCycleDelay        = 8;
SdramTiming.WriteRecoveryTime    = 5;
SdramTiming.RPDelay              = 3;
SdramTiming.RCDDelay             = 3;

/* Refresh Counter */
#define REFRESH_COUNT ((uint32_t)0x073F) // 1855 decimal

We are providing a 240 MHz clock to FMC, which is divided to 120 MHz for SDRAM operations. The refresh count is calculated by multiplying the SDRAM refresh interval (15.625 µs) by the SDRAM clock frequency (120 MHz), which gives 1875, and then subtracting 20 as required by the STM32 formula, resulting in a final REFRESH_COUNT of 1855(0x73F). Please refer to the earlier provided SDRAM datasheet for these specifications.

Before these modifications, we were getting around 42 ms frame rate instead of 16 ms, and after applying the new parameters, we are still observing the same result — no improvement in display refresh performance.

One additional observation: unlike the development kit MCU, which always run as HIGH & LOW logic level, our MCU is always at low logic. This difference in MCU behavior seems suspicious, and we are not sure if it could be affecting SDRAM or FMC operation. Could you please confirm whether this could be a concern?

Results and Source Files:

We are sharing the results we have obtained. The corresponding source files are available in the link provided below.

Observations:

• Upon comparing the results between the development kit and the custom PCB, the following differences were observed:

  • The development kit operates at approximately 16 ms.

  • The custom PCB operates at approximately 42 ms, as shown in the attached file.

Details of the Files:

• Test1: Custom application created with a self-written bootloader and external loader. Tested on DevKit (STM32H750XBH6).

• AP021_CB_Test1: Custom application developed for our custom PCB (STM32H750IBT6). This is the board where the current issue has been observed.

NOTE: we also have added logic analyzer results.

DRIVE LINK: https://drive.google.com/drive/folders/1gRN57SEOsggQLu3D-8KF0PUx5QgAT255?usp=sharing

We are quite new to this technology, could you please explain in more detail what might be happening or what additional areas we should review and please correct us if we are wrong anywhere.

Your guidance and corrections would be of great help for me and my team to understand and resolve this issue properly.

With best regards,

Geetha

[mƎALLEm]

Hello,

---

@Geethat wrote:

@mƎALLEm Thank you for sharing this image. Could you please let us know from which document this reference is taken? It would be very helpful for us to go through the complete section for better understanding.

---

Sorry, I thought I provided the reference of the doc:

It's the AN4861 "Introduction to LCD-TFT display controller (LTDC) on STM32 MCUs" /page 27

[DmitryR]

Good day Geethat,

first of all I want to point out that your link contains three different projects and also some "sal" files which I do not know how to open. Please advise what project do you want me to look. Then, the kit you are using has display resolution of 640*480 which needs 2,5 times less bandwidth than 1024*768 and in addition it requires not so much memory so most examples use internal MCU static memory for the frame buffer. Then, I have opened one of your projects and have seen a TouchGFX there. I would recommend first to set up the display without TouchGFX and only when it works right in a pure design to go further with TouchGFX. I also can say that the TouchGFX is far not the best graphic library. I do not know how it works - for example if it uses double buffering for rendering it may double memory bandwidth requirement. In this case do not forget to put the second buffer in the different bank of your SDRAM.

With best regards,

Dmitry