Ask a Question

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

5.7k 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
Thanks for your fast answer,

I comment lines like you propose to me, and it solve the issue on eval board. It solves also displaying a full screen image (320 x 240) on eval board and on my custom board.

But unfortunatly, my board can receive 2 flash references (one quad spi at 133Mhz and another quad spi at 104Mhz) and when I set flash SPI speed at 100Mhz (instead of 133Mhz) display is shifted.

Have you another solution to resolve displaying a full screen image on my board with flash reference at quad spi 104Mhz speed.

Regards
by
Hello,

to confirm that the problem still occurs in your environment, after the problem has happened, do you see the bit LCDIF_CTRL1[UNDERFLOW_IRQ] set? If yes, then you still get the LCD underflow.

Did you try with higher priorities of the LCD bus master (e.g. 5)?

Best regards,

Manfred.
by
Hello,

Yes, the bit LCDIF_CTRL1[UNDERFLOW_IRQ] is set when irq level is set to 0x02 or when set to 0x05, and display is always shifted.

Regards.
by
Did you adapt the MPU settings according to your memory layout?
by
Yes, MPU settings are adapted to my memory layout
by
Display shift seems to be resolves by changing pixel clock (BOARD_InitLcdifPixelClock function), but I'm not sure that calculation is correct.

First comment explain how to calculate pixel frequency for screen refresh rate. In my case (320 + 4 + 8 + 43) * (240 + 4 + 8 + 12) * 60 = 5.94Mhz (example gives (480 + 41 + 4 + 18) * (272 + 10 + 4 + 2) * 60 = 9.2M. Here set the LCDIF pixel clock to 9.3M)

Next comment explain how calculate parameters to configure video pll,

* Video PLL output clock is OSC24M * (loopDivider + (denominator / numerator)) / postDivider = 93MHz.

but I don't understand why result is 93Mhz (instead of 9.3Mhz, is tere a factor 10 ?)

I think also there is a mistake in formala, it should be (numerator/denominator instead of denominator/numerator) but these fields are set to 0 in example.

Using these formula, for rate refresh at 60Hz I obtain: .loopDivider = 39, .postDivider = 16, .numerator = 600, .denominator = 1000,   //Display refresh at 60Hz (pixel clk = 5.940M) (valid range for loopDivider is 27-54), but with these values I always have display shift.

I tried with 57Hz screen rate refresh and a full screen display is correct (clock video = .loopDivider = 37, .postDivider = 16, .numerator = 620, .denominator = 1000,   //Display refresh at 57Hz (pixel clk = 5.643M)

Could you comfirm if this approach is correct and will resolve my problem.

Regards
by
The display clock settings are taken from the examples that are provided within the MCUXpresso SDK.

Let me refer to these examples and to the RT1050 data sheet concerning all details about clock settings and divider...

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

...