Unfortunately I can't directly connect the mipi output to this LCD, so LT8918 is added, but I don't seem to have problems with that. The test pattern goes through well onto that device and also my debug log shows that it syncs and passes basic setup.
But I do get problems with the output. The current code I have is for a very simple small memory buffer (128x256) in the middle of 800x1280 screen. No need to look at the actual output screen, but it looks very distorted. Also in printed diagnostics I get a lot of underrun error as if the DMA is not getting data quickly enough for an entire row write.
So, I'm not any expert in LCDs or NXP registers. Am I making some dumb mistake somewhere? There's plenty of uncertainty. Is SRAM_OC1 actually quite slow? Maybe there's some AXI or DMA setting to get the timings right? I reconfigured it in the MPU code to be noncached, but maybe that also is a mistake. Unfortunately I don't see a difference whether it's default or ncache region. There are a lof of other things to consider, like I tried changing the stride length to be the entire 800pixel row instead of the smaller 128 layer 0 size. The RGB pixel clock is slower than the MIPI byte clock, but I'd expect MIPI to be much faster anyway because it has 2 lines instead of the RGB parallel 24 connections.
And also, the reason why I'm making such a small layer 0 area is because SDRAM might have errors. I am reducing this into a smaller controlled piece to get away from that uncertainty, but seems even in here I can't find exactly what's going wrong.
It's neat to have come this far but also quite frustrating that I don't see what to do to get more progress. The background single color displays all work fine, also the test patterns make nice-shaped bar regions, so I don't think it's a real 'LCD' problem, it looks instead like the RAM buffer read or LCDIFv2 putting that to the parallel output has some timing issue.
How could I debug this? Thanks.
I've tried a few more things, and now it actually looks like a stable output without underrun errors, at least according to my printed diagnostic. I think the primary change has been the first one, and other changes are a bit more difficult actually, but listing them for clarity. This particular setup is still RGB888 and I haven't wanted to change to experiment with alpha layer drawing yet as it's still not super good.
1. make the pixel clock much slower, down to a refresh closer to 15Hz. Maybe the DMA has extra time to work? But like you said, OCRAM should be fast. I have it set up to be an NCACHE region in that space too, in the MPU config.
2. the colors used are only black and white. Trying a green background actually introduces some background problems where the green can get shifted into an RGB pattern changing every row (off by 1 byte?).
3. the RAM layer 0 width is changed to 256 to match the height 256. Actually it's also fine as 128 height, just this particular log is 256 and you can see the stride changes too to 768.
4. The video settings for front porch and back porch are much bigger. I suspect this isn't the primary factor, I've also tried these settings at faster speeds, not super helpful. The datasheet maximum allows Hfp + Hbp + Hs to be as large as desired, is there any reason to have more than the 200 total here? Vertical settings are the ones limited to 250 altogether.
So anyway, it's interesting! Technically the LCD datasheet says that it should be run at minimum 22Hz, but I don't see flickering on the white section. I'd love to run it faster.
I haven't paid attention to DMA on RT1172 at all, is there anything to do to run it faster or give it more priority or something? Does LCDIFv2 have other settings for this? Particularly because OCRAM should be super fast, I'm surprised that slowing down so much had this effect.
Right. Thanks very much! Let's try more things. Here's another log.
I wanted to stick with RGB888. Is there some reason ARGB8888 would be better for this? I might try playing with alpha sometime.
CTRLDESCL5: 0xD8000260
I checked in the reference manual, the BPP setting is in bits 27-24, so that '8' indicates I successfully put it in RGB888, or so it seems. the last bytes seem unrelated and alpha settings seem harmlessly off.
The screen output looks different but not fixed. Perhaps improved? There's still wraparound, but less aggressive.
I've also experimented with increasing the speed of the pixel clock, not sure if that helps or hurts.
I could try more video setting changes? I had thought my 25% Hsync settings were very strong here, but then again, I've never done this before. What makes a setting particularly good? Is Vsync relevant too? There's a LT8918 bridge that also needs to get these settings input, but I can also manage that. Am I limited to guessing the right numbers to put in?
The driver is JD9365DA-H3, if that helps. This is a strange package with a touchscreen too, but I have no problems with that.
Hi @davidpspeedtech ,
Thanks for the update! However, the issue is that some of your settings aren't consistent.
- 0xD9000260 → the format latched in hardware is ARGB8888 (32-bit/pixel).
- So when you set stride = 384 (=128×3, RGB888), the hardware still fetches 128×4 = 512 bytes/row → per-line misalignment, reads past the buffer, and underrun.
You changed only the stride or the BPP macro each time, but the hardware actually obeys .pixelFormat, which stayed ARGB8888 — the four values were never consistent.
Please make them all consistent as 32-bit ARGB8888 or RGB888 in one shot:
CTRLDESCL3 should now read 0x200 (512). A 32-bit framebuffer and a 24-pin RGB888 output are independent — you do not need a 3-byte buffer for a 24-pin link.
Also these three lines use eLCDIF bit definitions; LCDIFv2 has no RUN bit and this can disturb the control state:
Gavin_Jia_0-1788249587860.pngGavin_Jia_0-1788249587860.pngGavin_Jia_0-1788249587860.png
please drive it only with standard APIs.
To confirm your other points:
- Stride is based on the RAM buffer width, not the screen width — correct.
- The background color is stable because it is register-generated (no memory fetch); this proves the output path is fine and isolates the fault to the layer fetch path.
- The color buffer flickering between primary/secondary colors ("like a byte is lost") is exactly underrun dropping bytes; it should disappear once the format is consistent.
- Bandwidth is not the bottleneck (OCRAM, 128-wide). If underrun still remains after this, lower the pixel clock or increase HBP/HFP to confirm.
Well, that doesn't fix it. Actually whether the stride is 128*3 for RGB888 or whether it's 800*4 setup for ARGB8888 and trying to put the entire screen into RAM, the output looks rather similar with distortion off the edge of the screen and I still get underrun errors. I've tried a lot of settings, not only the text in those files!
#define SMALL_LAYER_0_HEIGHT 256U
#define SMALL_LAYER_0_WIDTH 128U
#define SMALL_LAYER_0_BPP 3U /* RGB888 */
#define SMALL_LAYER_0_STRIDE (SMALL_LAYER_0_WIDTH*SMALL_LAYER_0_BPP) /*384*/
~debug print~ CTRLDESCL3: 0x 180 (Pitch/Stride = 384 bytes)
Again, that also doesn't work.
But I'm happy that you can confirm that my layer 0 stride setting should be based on the RAM buffer width and not based on the LCD screen width. Right?
Since the interface to LT8918 has a 24 pin parallel connection it really should be RGB888. I am concerned sometimes that DMA or something isn't keeping up, but this is running out of SRAM_OC1 with the tiny buffer size. Perhaps even RGB565 would have similar output because the most significant bits could be output correctly on their RGB pins. I might even try something monochrome.
I might be making more mistakes as visible in the sample code with the BPP set to 4 instead of 3 for RGB888.
Is there any requirement to have the 'background area' in a different layer and buffered in some other memory? I like that the background setting seems to work correctly and the output color there is stable at whatever solid color I set it to. Some experimenting with non-white RAM buffers allow the screen to flicker between primary (RGB) or secondary colors, like an individual byte is lost, perhaps.
Hi @davidpspeedtech ,
Thanks for your interest in NXP MIMXRT series!
I reviewed the attachments you provided, and some of the settings may need to be adjusted.
CTRLDESCL3: 0x00000C80 (Pitch/Stride = 3200 bytes)
- CTRLDESCL3 (PITCH) = 384 (0x180), i.e. SMALL_LAYER_0_STRIDE = 128 * 3.
- Buffer base address 64-byte aligned; keep it non-cacheable (your current setting is correct) or clean the D-cache before display.
Best regards,
Gavin
Hi @davidpspeedtech ,
The descriptor is now self-consistent: CTRLDESCL5=0xD8000260 (BPP=8=RGB888), CTRLDESCL3=0x300=768=256×3. You read it correctly.
But the underlying mismatch is still there; it's just masked by the low clock. The color "changes every row, like a byte is lost" is the proof: your memory dump is all 0xFFFFFFFF and Center Pixel reads one pixel as a single 32-bit word — i.e. the content is still 32-bit/pixel while the hardware fetches 3 bytes. White is 0xFF in every byte so it hides it; green drifts per line.
Lowering the pixel clock "removes" the underrun, but not because OCRAM is slow (OCRAM is fast, on-chip memory is not the bottleneck). Underrun depends on LCDIFv2's fetch throughput as an AXI master. You dropped the refresh to ~13.5 Hz (18.85 MHz ÷ (1000×1400)), cutting the fetch demand 3–4×, so it stops — but that's below the panel's minimum.
To run fast without underrun, these may helps:
- Switch to ARGB8888 end-to-end:
.pixelFormat=ARGB8888, BPP=4, stride=256×4=1024, buffer at 4 bytes/pixel, and make sure the pixel-writing code writes 32-bit words. Two reasons: (a) it matches your existing 32-bit content → fixes green; (b) the RM notes packed RGB888 issues bursts of length 15 on the bus (less efficient, more underrun-prone), while ARGB8888 is 32-bit aligned with clean length-16 bursts. Verify with a green dump: it should be a clean repeat, not drifting per row. - Raise the LCDIFv2 b_clk (clock root) and restore the pixel clock to ≥22 Hz — that's the correct lever for speed, not lowering the clock. LCDIFv2 does not use eDMA, so "raising DMA priority" doesn't apply; the available levers are b_clk, burst length, outstanding requests, and the THRES dynamic-priority threshold.
- Take the timing from the JD9365DA-H3 panel datasheet — don't guess — and match the LT8918 input timing to it. ~200 horizontal blanking is fine; larger blanking eases underrun but raises htotal (needing a higher pixel clock), so it's a trade-off — the root fix is a higher b_clk. Vsync/vertical porch must match the panel but have little effect on per-line underrun.
Best regards,
Gavin