Skip to main content

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
Asked
Modified 1 month ago
Viewed 55 times
2
\$\begingroup\$

I am currently using the STM32N657 on the NUCLEO-N657X0-Q board to drive an 800×480 pixel display with 24-bit color.

The display that I am using is the NHD-7.0-800480EF-ASXV#-T. I’m using the built-in LTDC controller on the chip. I do know that the controller is working because the entire screen is black, the screen would be showing the backlight if it wasn’t. The problem is that I am unable to display anything at all when writing to the screen buffer.

Here are the configuration parameters that I am using based on the data sheet:

Parameter Settings

Here are the layer settings that I am using:

Layer Settings

Here is the clock configuration for the LTDC:

Clock Config

Here is the code that I am running:

#include "main_application.h"

__attribute__((section(".screen_buffer")))
uint8_t screen_buffer[FRAME_BUFFER_SIZE];

void main_app(hal_pointers_t hal_pointers){

    for (uint32_t i = 0; i < FRAME_BUFFER_SIZE; i++){
        screen_buffer[i] = 0;
    }


    HAL_LTDC_SetAddress(hal_pointers.hltdc, (uint32_t) screen_buffer, 0);
    //HAL_LTDC_ReloadLayer(hal_pointers.hltdc, LTDC_RELOAD_IMMEDIATE, 0);
    //HAL_LTDC_SetOutputDisplay(hal_pointers.hltdc, LTDC_OUT_RGB);

    //Make a square
    for (uint32_t i = 0; i < FRAME_BUFFER_SIZE/3; i++){
        //for (uint32_t j = 0; j < 20; j++){
            //screen_buffer[(i*3) + (j*SCREEN_WIDTH*3)] = 255;
            screen_buffer[i*3] = 0x55;
        //}
    }

    while(1){
    }

}

Here is what I’ve observed:

  • I have run the code in debug mode and can see data being written at the screen buffer location

  • I’ve hooked up a logic analyzer to the red data pins, HSYNC, VSYNC, DE, and DCLK (below is a snapshot). When the red data pins are not active HSYNC seems to be acting somewhat normally. When the data pins are active, HSYNC does not act normal at all. It pulses almost randomly. Please note that the logic analyzer is a cheap one from Amazon, so it may not even be reading this data correctly.

Bad HSYNC

Good HSYNC

Here's what I’ve tried:

  • I’ve tried using the following HAL functions:

    • HAL_LTDC_ReloadLayer(hal_pointers.hltdc, LTDC_RELOAD_IMMEDIATE, 0),
    • HAL_LTDC_SetOutputDisplay(hal_pointers.hltdc, LTDC_OUT_RGB).

    No change.

  • I’ve tried slightly adjusting the pulse width settings for both HSYNC and VSYNC. No change.

Let me know if I’ve forgotten to provide any information.

\$\endgroup\$
1
  • \$\begingroup\$ Have you tried changing layer colour or alpha values in any way to see if the output changes to e.g. red? Is 255 fully transparent or fully opaque? \$\endgroup\$
    Justme
    –  Justme
    2025-08-27 19:28:17 +00:00
    Commented Aug 27 at 19:28

1 Answer 1

1
\$\begingroup\$

To anyone who stumbles upon this post. I figured out what my issue was. I was using AXISRAM to store my screen's buffer memory, which by itself is fine. What I didn't realize is that the LTDC peripheral does not initially have access to this memory. In order for the display data to get to the LTDC peripheral, you need to use the RIMU.

LTDC block diagram

In order to enable the RIMU you need to enable RIF in the hardware configuration. Make sure to enable it whether you are running your main code in application or in FSBL.

RIF Hardware Config

Then go to the RIF tab on the top, go to "Domains (RIMU)" tab on the side, and then give LTDC_L1 (Layer 1, or whichever Layer(s) you are using) privilege and secure status. The way that I understand it, you are telling the microcontroller that the LTDC can have full access to system resources (privilege) and is a trusted peripheral (secure).

RIMU Hardware Config

Once you do that, you need to add these lines of code.

RIMC_MasterConfig_t RIMC_master = {0};
RIMC_master.MasterCID = RIF_CID_1;
RIMC_master.SecPriv = RIF_ATTRIBUTE_SEC | RIF_ATTRIBUTE_PRIV;
HAL_RIF_RIMC_ConfigMasterAttributes(RIF_MASTER_INDEX_LTDC1 , &RIMC_master);

HAL_RIF_RISC_SetSlaveSecureAttributes(RIF_RISC_PERIPH_INDEX_LTDCL1 , RIF_ATTRIBUTE_SEC | RIF_ATTRIBUTE_PRIV);

These lines of code basically do what the hardware configurator is supposed to do when giving the LTDC layers security status and privilege status. I'm not really sure why the hardware configurator doesn't write these lines of code for you, unless it's not being written somewhere else that isn't main.c. You will want to write these lines of code before you set the memory address or addresses for any of your LTDC layers.

As soon as I made these changes, I immediately saw color on my screen.

Color on Screen

\$\endgroup\$

Your Answer

Post as a guest

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.

Morty Proxy This is a proxified and sanitized view of the page, visit original site.