Display is shifted when images are read from flash memory (directAccess project option set for bitmap)

asked Jun 3, 2019 in System Integration by christophe_rtone.fr


I'm using an imx rt 1052 nxp processor on a custom board and I see that when I use large images on my application, display is shifted when large images are displayed (100 x 100). 

This feature is active only when images are read directly from flash memory.

I'm also able to reproduce this issue on nxp MIMXRT1050-EVK eval board with ColorFormats example provide by EW when setting formatOfBitmapResources project option to directAccess. This example run well when option is set to compressed. BrickGame example also show problem with directAccess for images.

My custom board has only 512Kb internal RAM memory, and only 288Kb are available for Embedded wizard application (150Kb for frame buffer and 138Kb for memory pool for 320 x 240 screen), so I'm not able to display large image with so little memory, but it is possible when images are stored in flash memory (except with this issue).

Display screen shot:



1 Answer

0 votes
answered Jun 3, 2019 by Manfred Schweyer


I have observed the same issue and we did further analysis together with the NXP support team. The reason for the shift effect is a LCD underflow. This means, the LCD controller does not get enough data from the internal bus.

I assume you are using version 9.20 of Embedded Wizard and the RT1050 Build Environment - there you will find a prepared solution to avoid the LCD underflows.

Please have a look into the file /TargetSpecific/ew_bsp_display.c - there you will find the following code snippet within the function EwBspConfigDisplay():

  /* In case you get LCD underflows (e.g. flickering of LCD while PXP is active),
     you can increase the read priority for the LCD by modifying the NIC read_qos
     value for it. It is at 0x41044100 (register that isn’t in the header file)
     The default value is 1 which is a pretty low priority.
     If you change this register to a value grater than 1 (up to 5), then that
     will make the LCD higher priority. It should solve the underflow issue.
     If it creates a problem for another master, then you might need to experiment
     with the value to find something that keeps the LCD from underflowing, but
     allows enough bandwidth for other masters.
    uint32_t* LCD_read_qos = (uint32_t*)0x41044100;
    *LCD_read_qos = 0x02;

Just uncomment that in order to increase the priority of the LCD controller.

Does this solve the shift problem in your environment also?

Best regards,


commented Jun 27, 2019 by Hafees

Is this issue resolved?

I am also getting a similar issue (display under run error) in our target board which is based on i.MXRT1050 (display 800x480).

The issue is happening after migrating to 9.2 version! Previous to this we were using 9.0 version, and display was working fine.

Best regards

commented Jun 27, 2019 by Manfred Schweyer
Hello Hafees,

within version 9.0 the PXP hardware was not used - therefore the issue can appear only with 9.2 version.

Did you try to change the LCD bus master priority as mentioned above?

Best regards,

commented Jun 27, 2019 by Hafees

Infact, LCD_read_qos was set to 0xF with version 9.0 itself. This was suggested by NXP some time back due to a display flickering issue in our custom board.

With this setting, display was working upto 25MHz pixel clock (~45 FPS) without any issue.

Now, with version 9.2, the same display/clock configuration is not working(shifting) . I was able to see a stable display when I reduce the pixel clock to ~10MHz (~16FPS).

Best Regards,

commented Jun 27, 2019 by Manfred Schweyer


well, since version 9.10, the PXP hardware is used in order to accelerate the graphics composition.

This means, that at least three bus masters (CPU, PXP, LCDIF) have to share the available memory bandwidth. 

If you want to disable the usage of the PXP hardware, you can call NxpRtUsePXP( 0 ) after the initialization of the Graphics Engine. Then you should have the same behaviour as it was the case with version 9.0 - of course, with lower performance.

Which color format are you using? If you are using RGBA8888 or RGB888 color format, you can try to use RGB565 instead in order to reduce the memory bandwidth used by LCDIF.

Are you using double buffering or single buffering of the framebuffer?

Best regards,


commented Jun 27, 2019 by Hafees

Thank you for this information.

FYI. In the display shift error scenario, LCD UNDERFLOW flag was NOT getting set  ( LCDIF_CTRL1). Probably the PXP bus priority may need some udjustments, I guess. We will try adjusting the bus priority for CPU,PXP & LCDIF to have an optimal value.

For the time being I have disabled the PXP and it is working as you mentioned.

Currently we are using RGBA8888 format. We are planning to move to RGB565 very soon.

We are using double bffering for the frame buffer.

Best Regards


Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint