NHD-3.5-320240FT-CTXL-CTP Eve2 co-processor issue
Hi,
I am using Newhaven EVE2 Display over SPI with TI MCU.
The application has simple pages, which all have background image and a button. "The button" is a a tagged image as well. When the button area is touched ,an another page will be displayed. The corresponding series of commands is first written to MCU buffer, and then transmitted to the display command queue, which is then executed, and display swapped.
The application works mostly. The page changes work as desired, but after some 5 or 6 changes the display goes crazy. It may display just one color, or the background image rasterized wrong, or just stripes etc. I've verified that the commands are written without error by dumping the CMD buffer.
A test program which has just the tagged button images, and no background, does not go crazy, but it responds slower after half a dozen page changes. I reduced the program to just two pages changing back and forth, and the issue still takes place.
The common thing seems to be that the problem appears after the display CMD buffer has received altogether about 0x400 bytes worth of commands (1024 bytes) in several transfers. 1024 is nowhere near the CMD buffer size mentioned in datasheet. The buffer size is checked before writing to.
Also, the display is not in error state either.
After reading back the interrupt flags from the display, it seems that the display registers touch events, and the MCU application receives them, and is able to send new display commands, but the display is already crazy and shows wrong stuff.
Doing the software reset to the display does not change the situation.
Tested with 2 identical displays.
What could explain this?
I am using Newhaven EVE2 Display over SPI with TI MCU.
The application has simple pages, which all have background image and a button. "The button" is a a tagged image as well. When the button area is touched ,an another page will be displayed. The corresponding series of commands is first written to MCU buffer, and then transmitted to the display command queue, which is then executed, and display swapped.
The application works mostly. The page changes work as desired, but after some 5 or 6 changes the display goes crazy. It may display just one color, or the background image rasterized wrong, or just stripes etc. I've verified that the commands are written without error by dumping the CMD buffer.
A test program which has just the tagged button images, and no background, does not go crazy, but it responds slower after half a dozen page changes. I reduced the program to just two pages changing back and forth, and the issue still takes place.
The common thing seems to be that the problem appears after the display CMD buffer has received altogether about 0x400 bytes worth of commands (1024 bytes) in several transfers. 1024 is nowhere near the CMD buffer size mentioned in datasheet. The buffer size is checked before writing to.
Also, the display is not in error state either.
After reading back the interrupt flags from the display, it seems that the display registers touch events, and the MCU application receives them, and is able to send new display commands, but the display is already crazy and shows wrong stuff.
Doing the software reset to the display does not change the situation.
Tested with 2 identical displays.
What could explain this?
0
-
Well, this turned out to be a problem in the code which sends data to the display. Temporary buffer read pointer did not advance correctly, so it copied the new data and all previous display lists to the cmd queue, with the described results. Also REG_CMD_WRITE and REG_CMDB_WRITE look very similar but aren't.
0
Please sign in to leave a comment.
Comments
1 comment