I observed an issue with a 1024x600 pixel LCD connected to an iMXRT1052. The problem is that the screen content is shifted by an arbitrary number of pixels. The screen content is loaded from an external NAND-Flash The result looks like this:
I found the solution here:
It seems that the LCD controller had an underflow of data.
I could finally resolve the issue by changing the priority of the NIC-301 LCD-read_qos register from 1 to 11 (see Reference Manual 29.4) like this:
uint32_t* LCD_read_qos = (uint32_t*)0x41044100;
*LCD_read_qos = 11;
I find it curious that the default priority value is 1which is obviously not sufficient.
I was wondering if anyone else had a similar issue?
已解决! 转到解答。
Hi,
we figured out an additional important setting (thanks to the AN12302: i.MX RT eLCDIF RGB Mode Use Case: Chapter 4. eLCDIF demo and performance tuning):
ELCDIF_AXIMasterFeature(LCDIF, kELCDIF_AXI_burst_len_8 | kELCDIF_outstanding_req_8);
This sets the "LCDIF General Control2 Register" (see eLCDIF chapter in RM) and allows for using a lower priority value of 5 (instead of 11).
Kind regards,
Johann
Hi,
we figured out an additional important setting (thanks to the AN12302: i.MX RT eLCDIF RGB Mode Use Case: Chapter 4. eLCDIF demo and performance tuning):
ELCDIF_AXIMasterFeature(LCDIF, kELCDIF_AXI_burst_len_8 | kELCDIF_outstanding_req_8);
This sets the "LCDIF General Control2 Register" (see eLCDIF chapter in RM) and allows for using a lower priority value of 5 (instead of 11).
Kind regards,
Johann
Hello Johan,
This behavior is specified in a comment of the SDK. It's up to each customer to modify this value according to their needs. Within the SDK we recommend that value doesn't be greater than 5. If you put 5 instead of 11, do you still face the shift behavior?
Regards,
Victor