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

[unsigned_char_array]

---

@DmitryR wrote:

And one more advice. Latest STM32H7 chips have LVDS transmitter inside.

---

Which models? I couldn't find any reference to LVDS. I only see some support MIPI-DSI, none support LVDS directly. We use an RGB to LVDS conversion chip.

[DmitryR]

Good day @unsigned_char_array 

yes, I have meant MIPI-DSI. MIPI-DSI also uses LVDS signaling. 

With best regards,

Dmitry

[Geethat]

@DmitryR 

Test1 is an application created for the STM32H750 development kit.

AP021_cb_test1 is an application created for our custom board, which uses the STM32H750IBT6 MCU.

The development kit uses the STM32H750XBH6 MCU.

Please find the attached images of the .sal file, which are the logic analyzer outputs.

Chn0(D0)- render time
Chn1(D1)- frame rate

render timeframe rate

[Geethat]

Hi @DmitryR 

We are waiting for your reply it would be very helpful for us.

Thank you

[DmitryR]

Good day Geethat,

once again, what exactly answer are you waiting from me? These timings look pretty good. Did you have considered things that I have written in my previous comment?

With best regards,

Dmitry

[Geethat]

Hi @DmitryR 

There are two cases 

Case 1: Development Board

In the development board, we tested two applications:

1. Designer (TouchGFX) Application:

   • MCU output signal toggles high and low correctly.

   • Rendering time: 16 ms (perfectly stable).

2. Customized Application:

   • MCU signal remains low continuously.

   • Rendering time: 16 ms, which is also perfectly stable.

Components used in the Development Board:

• SDRAM: MT48LC4M32B2B5-6A IT_L TR

• QSPI: MT25QL512ABB8ESF-0SIT

• Display: MIPI display with RK043FN48H-CT672B IC

Case 2: Custom Board

In our custom board, we tested the customized application, and the following behavior was observed:

• The MCU signal always stays low.

• Rendering time observed is 44 ms on the custom board, whereas it is 16 ms on the devkit custom application. I have followed the same procedure while creating the application for my custom board. 

Components used in the Custom Board:

• SDRAM: IS42S32400J-6TL

• QSPI: MT25QL512ABB8ESF-0SIT (same as dev board)

• Display: LVDS display using DS90C385AMTX_NOPB DRIVER

 Issue

• In the development board, both applications run at 16 ms rendering time, even when the MCU signal is low for the customized application.

• In the custom board, the MCU signal also remains low, but the rendering time increases to 44 ms.

• The main hardware differences are the SDRAM and display interface (MIPI vs. LVDS).

We Would Like to Understand

Even though we have followed the same procedure in creating the customized application,

1. Why is the MCU signal always low in customized applications?

2. Why is the rendering time 44 ms on the custom board, while it is 16 ms on the development board even though we have followed the same procedure as followed in dev kit for creating the application?

Attachments

A Google Drive link is provided containing the following:

1. STM32H750_DEVKIT – includes customized and designer applications, schematics of the development board, logic analyzer details.

2. STM32H750IBT6_CUSTOMIZED_PCB – includes the customized application and schematics of our custom PCB.

https://drive.google.com/drive/folders/1gRN57SEOsggQLu3D-8KF0PUx5QgAT255 

Custom PCB custom application test result: 

Showing 44ms rendering time and mcu active low.

custom board custom application results

NOTE: To open both the customized and development board application files which are in ".sal" format, please install this application https://support.saleae.com/product/logic-software/sw-download \

Thank you for your time and support, your reply will be very helpful for our further steps.

[DmitryR]

Hello Getthat,

I do not understand what MCU signal stays low and why is it so important. For the rendering time I have already answered: you are using display with a 2,5 times higher resolution that on the kit so the rendering time is higher accordingly.

With best regards,

Dmitry  

[unsigned_char_array]

---

@Geethat wrote:

Hi @DmitryR 

In our custom board, we tested the customized application, and the following behavior was observed:

• The MCU signal always stays low.

---

I have a custom board and I had to implement the MCU signal myself. It wasn't enabled by default.
I don't use an RTOS so I made my own idle loop architecture.

void (*idleTask_p)(void) = nullptr;

void OSWrappers::takeFrameBufferSemaphore()
{
    if (fb_sem)
    {
        if (idleTask_p != nullptr)
        {
            while (fb_sem)
            {
                idleTask_p();
            }
        }
        else
        {
            while (fb_sem);
        }
    }
    fb_sem = 1;
}

void OSWrappers::giveFrameBufferSemaphore()
{
    fb_sem = 0;

    if (idleTask_p != nullptr)
    {
        idleTask_p();
    }
}

void OSWrappers::tryTakeFrameBufferSemaphore()
{
    fb_sem = 1;

    if (idleTask_p != nullptr)
    {
        idleTask_p();
    }
}

In your idle task you can set MCU_active to false at the start.

int main(void)
{
//..
idleTask_p = mainLoop;
while(1)
{
    mainLoop();
    MX_TouchGFX_Process();
}
}
static void mainLoop()
{
    // set mcu active to false
  
   // do non TouchGFX things here

    // set mcu active to true
}

in TouchGFXHAL.cpp, which is used when using FreeRTOS, it is implemented for you:

    portBASE_TYPE IdleTaskHook(void* p)
    {
        if ((int)p) //idle task sched out
        {
            touchgfx::HAL::getInstance()->setMCUActive(true);
        }
        else //idle task sched in
        {
            touchgfx::HAL::getInstance()->setMCUActive(false);
        }
        return pdTRUE;
    }