ST7701 drivers

[SolitoFrancesco]

Hello

I'm trying to communicate with a ST7701 display controller.

Are some examples available? Can anyone share if possible?

I'm using an i.MX RT1170 board. In the SDK examples I found the drivers for the HX8394, RM68191 and RM68200 display controllers. I would like to find something similar for ST7701.

Can anyone help me please?

Thank you and kind regards,

Francesco Solito

[EdwinHz]

Hi @SolitoFrancesco,

At the moment, we don't have any driver support in our SDKs for the ST7701 display controller. The integration with this controller would have to be done manually.

It is important to adjust the resolution values, synchronization signals and clock frequencies of the LCDIF module to allow compatibility with the display controller. If using the EVK, you can use the SDK drivers and adjust the values of the following functions:

• BOARD_InitLcdifClock()
• BOARD_InitMipiDsiClock()
• BOARD_SetMipiDsiConfig()

These functions along with the macros for the synchronization values and are all referenced on the "display_support.c" file, which will be the main file to focus on when adjusting the support for your display controller.

Also make sure to look into the following application note, as it goes into a lot more detail about how the setup for an LCD display works and other useful considerations: i.MX RT eLCDIF RGB Mode Use Case (nxp.com) 

BR,
Edwin.

[SolitoFrancesco]

Good morning

I modified the files you mentioned, following the indications that I received from the display manufacturer and from the driver manufacturer. I'm able to write and read into the driver registers through MIPI. I can see the differential MIPI waveforms with oscilloscope (also after the "configuration" phase), but I'm still not able to see anything on the display. I'm using the demo example from NXP SDK called "mipi_dsi_compiance_test".

Can you please try to help more?

Thank you and kind regards,

Francesco Solito

[EdwinHz]

Hi @SolitoFrancesco,

Have you been able to debug your code while running? Do you see any error message being printed? And what data patterns do you see on the data line? Do these patterns coincide with the expected ones described on the readme.md file?

BR,
Edwin.

[Rino]

Hello,

I have the same situation (same driver and resolution, and the base is a test example that worked on the devboard). The controller is configured, and I can also read the statuses (without any errors), and the data on the DSI lines is present, but the screen displays nothing.

Changing the videoMode in dsi_dpi_config from kDSI_DpiBurst to other modes also has no effect.

It looks like the screen isn't accepting the video stream? 

[SolitoFrancesco]

Hello. The example project works correctly with the display DEMO_PANEL_RK055MHD091. Then I switched to the panel that I have to use in my final application. It has different resolution (480x800) and so I adapted the defines. Then I changed the drivers (fsl .h and .c files) and I'm able to communicate with my display. I can write and readback the registers. But after the configuration of the display, when the example project starts sending the image buffer, I can see the MIPI waveforms on the oscilloscope, but nothing on the display. Consider that the display is not broken, because I tried to turn on all the pixels through the dedicated command and I can see the screen completely white. What I don't understand is if the problem is in the configuration of the display or in something else that I have to adapt in the example project. I contacted the display manufacturer and the controller manufacturer, but I need as much help as possible from all sides. Is it possible to get the fsl drivers for the controller that is mounted in my display? It is a Sitronix ST7701. Please let me know. Thank you and kind regards, Francesco

[Rino · Accepted solution]

Hello Francesco, 

I managed to get the display working.

In the DisplayTFT_SetMipiDsiConfig function, add the line:

dsiConfig.enableNonContinuousHsClk = true;

for example, after these lines:

DSI_GetDefaultConfig(&dsiConfig);
dsiConfig.numLanes = DISPLAY_MIPI_DSI_LANE_NUM;
dsiConfig.autoInsertEoTp = true;

Assuming you have the display IC configured correctly (if necessary, I can share the configuration for my screen) and the display clock (my settings are around 26MHz).

Best regards, Chris

[SolitoFrancesco]

Hello Rino

Thank you very much for your suggestion. It seems to work also in my application. Great. I probably need to better setup something, but now I can see the image on the screen.

Please if possible share your configuration, so I can compare with mine to better refine it. If I see something different I'll tell you here.

Thank you again. Where did you came up the the enableNonContinuousHsClk setting?

Kind regards,

Francesco

[Rino]

Hello, 

the file was created based on other drivers in the SDK.
You can still change the delays to shorter ones.

This morning, I confirmed the configuration sequence and made a few changes as recommended by the display manufacturer, but there was no further improvement, so I started taking a closer look at the DSI configuration itself. I know the clocks were fine, and so was the video mode (burst mode), so the only options left were those for the DSI itself.

Familiarizing myself with (and other parts in docs):

https://docs.nxp.com/bundle/AN13573/page/topics/continuous_vs_non-continuous_clock.html

BR, Chris 

[SolitoFrancesco]

Hello Rino

I'm making a comparison between my settings and yours (at the end I'll upload here).

In the meanwhile, what I noticed is that I'm using a ST7701, instead you are probably using a ST7701S (with S suffix). I think they are similar but I'm not sure.

The thing that I noticed is that the display now works even if I don't make any initialization at all. It starts "slowly" and with low britghteness, but it works. Then, if I only sends the settings from 0xE0 to 0xEF (that aren't documented in the ST7701 datasheet), the display start up very fast and with the correct colors. It seems that all the other settings are not necessary (it sounds strange).

Let's keep in touch. I'll share the comparison when I'm finished.

Thank you very much again.

Kind regards,

Francesco

[SolitoFrancesco]

Hello Rino

As promised, please find in attachment the settings comparison between yours and mine. I didn't go in details, but if me or you will find something interesting in the differences, please let's continue to write here.

Kind regards,

Francesco

[Rino]

Hello Francesco,

Sorry for the delay.

I looked through your comparison and noticed a lot of differences, partly due to the screens themselves (we have a glass/touch/screen sandwich, and there was a configuration fix for that – or at least that's what the supplier explained ).

Some settings, like power control, aren't required for startup, but for quality improvement (contrast/gamma settings).

And what's funny is that the whole "Sunlight Readable Enhancement" thing, I think they called it, is required, regardless of whether we're running it or not. Based on this data, it automatically sets optimal parameters. If they're incorrect or missing (default values), it takes a while to automatically set them -> hence the slow startup, as you've noticed.

The documentation itself can be quite irritating, many of the commands are undocumented, and without them, it's often impossible to fully start the screen. This isn't just with this model, I've encountered this with several other Sitronix models.

Kind regards,
Chris