5.6k views
in System Integration by

Hello,

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:

          

Regards

1 Answer

0 votes
by

Hello,

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,

Manfred.

by
Hello,

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

Hafees
by
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,

Manfred.
by
Hello,

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,

Hafees
by

Hello,

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,

Manfred.

by
Hello,

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

Hafees

Embedded Wizard Website | Privacy Policy | Imprint

...