Hi,

I'm running emWin on an STM32F103ZET6, using FSMC as interface to connect with the LCD driver(SSD1963).

For touch, I have written my own driver, and use GUI_TOUCH_StoreStateEx function to store registered x, y.

Touch screen works fine, accuracy is acceptable, but all the points that cursor has been are marked with a ghost of the cursor, as if I'm in a paint program and I'm drawing something.

I have gone both with and without OS (FreeRTOS) and the result is the same. Besides, the cursor shape (Arrow or whatever) tend to become somehow deteriorated, like if some pixels of it are misaligned, missed or like that (the placement of deteriorated pixels is random and changing).

Has anybody had this problem? What am I doing wrong?

Thank you.

Ok, one problem solved.

I connected pin RD (Read) of SSD1963 to VDD, somewhere nearest to the IC. It helped remove the deterioration of cursor shape.

Now I have a perfectly and neatly shaped cursor, but it still leaves its footprints on the LCD.

Come on! Only 8 views so far?! Someone help me!

I realize that during touchscreen moves, WM_PAINT message is not being sent to the call back function. Is that a clue?

If I invalidate the region cursor has been, it helps because invalidation makes Window Manager pass WM_PAINT message, hence cause cursor footprint clearing.


So, I conclude that touchscreen cursor at the moment does not invalidate the area it has been, why not?

Hello Adrian,

Thanks for the reply, I was getting disappointed.

Touchscreen driver IC is XPT2046, which is ADS7846 compatible. I have created a task which reads X and Y from the touch screen, maps it to LCD coordinates and uses
"GUI_TOUCH_StoreStateEx" to save PID state (layer 0).


I NEVER call GUI_TOUCH_Exec(), and as I said before, cursor movement is fine.

Can you provide a sample driver code?

Thanks again

P. S.:
I ran the sample program "Showing sprites" to see how sprites worked.

The background and Segger logo are shown perfectly, but no sprite (dolphins) appears.

Debug reveals that there is no hard fault or things like that, what does it mean?

Well well well...

I found an old topic here:

emWin Mouse


In which it seems exactly the same problem is being encountered.

Due to some noise problems, I have shorted the RD pin of the controller to VDD. Does emWin need to read data from the LCD driver chip (SSD1963)?

I debugged the sprite code mentioned in my previous post, and saw some calls to the routines that read from the LCD driver, but they seem to happen just at the beginning of the program (during initialization?) .

P. S.:
Reconnected RD pin from SSD1963 to NOE pin on STM32, as it should be. I suspect what I thought to be a noise problem actually might be an LCD read problem.

Anyway, sprites did not appear, cursor still is leaving footprints, although the color of footprints is changed and the cursor shape is a little bit deteriorated (some pixels missing).

Besides, LCD becomes washed out sometimes (What I thought to be a noise problem).

Is there a chance I might have damaged the pins? I should check it with an oscilloscope.

I reconnected the RD pin. No physical damage.

During my searches, I found out this function was missing in my codes:

GUIDRV_FlexColor_SetReadFunc66720_B16(pDevice, GUIDRV_FLEXCOLOR_READ_FUNC_II);


So I added it to LCDConf.c

Then I wrote a very basic code that clears LCD with Red, Green ... and enabled cursor as well.

Only the 0,0 point, were cursor has been at the beginning of application, is redrawn correctly, every other place is drawn black.

I checked what was read back from LCD using debug (I used Keil Uvision), and realized that color codes are read back correctly, 0x001F for red, 0x07E0 for green, 0xF100 for blue. Also checked yellow, result is 0x07FF, which is correct.

So, I conclude that colors are read back from SSD1963 correctly.

Then I tried this code:


GUIDRV_FlexColor_SetReadFunc66720_B16(pDevice, GUIDRV_FLEXCOLOR_READ_FUNC_I);


(FUNC_I instead of FUNC_II). Although places cursor has been are not redrawn correctly, but the color changes depending on the background of the cursor. It differs from previous results, which were always plain black.

Any ideas?

Problem Solved!

It was an LCD driver problem! In LCDConf.c I did:

1. Add GUIDRV_FlexColor_SetReadFunc66720_B16(pDevice, GUIDRV_FLEXCOLOR_READ_FUNC_II); to the function: void LCD_X_Config(void)

2. Add Config.NumDummyReads = -1; to the same function (before GUIDRV_FlexColor_Config)

Number 2 is very important, by default, Config.NumDummyReads is set to 0, which is invalid. if you don't need any dummy reads, Config.NumDummyReads must be -1, not 0.


Besides, your microcontroller must be able to read data from LCD, because in most cases it does not have a copy of LCD contents internally, it cannot figure out how to restore the colors where pointer has been before.

That's it! I can't believe it took me such a long time to get fixed!

Hello Adrian,

Thank you. The confusing thing was that I checked many LCDConf.c files and none of them had this value set to -1.

They didn't bother to change this value at all, and I wonder how their drivers worked then!

Thanks again.