2.2" SPI LCD (ILI9341) crashed by nearby UMTS phone? - Page 1
Forum section: electronics / projects

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 13, 2015, 03:10:30 pm
content: I recently started playing around with a 2.2" SPI LCD display for <5€ which uses an ILI9341 controller.Something like tihs:http://www.ebay.de/itm/171582325045?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AITCurrently everything is wired on a breadboard with a lots of jumper cables but still the display works for SPI clocks up to 10MHz (16bit write data).However I noticed that now and then, the display became white like it is directly after power-up (no init commands send, display off).First I suspected a bug in my own code but I could see that my microcontroller was still running, still sending commands and data to the display and it was the display that was frozen.I then added code to check the self diagnostic result every seconds or so and perform a re-initialization of the display (SW reset, some configuration, sleep out, finally display on and filling the display RAM) but this didn't help. I could see that the code was reached after display freeze, but it didn't fix the issue.I could also see that the fault detection and re-init worked as supposed after a HW reset, but only if I performed the HW reset during normal operation.After the display freeze, not even a HW reset followed by a re-init brought the display back to life. Only removing the power for some seconds did.Finally I wondered if my smart phone that was sitting next to the breadboard could cause this issue and after some testing, I was pretty much convinced that this is the case. I put my phone half a meter away and the display didn't freeze in ten hours endurance test. When the phone was a few centimeters away, it usually crashed after some minutes. Tried with three different displays. All behaved the same.Well, then again today I was not able yet to produce a freeze even though the phone is sitting directly next to the display. Maybe it just takes more time, maybe my conclusion was wrong even if it looked to convincing yesterday.So did anybody observe the same behavior? Any ideas how to recover from that frozen state without using a FET to switch off the power to the display?BTW: while SW reset, sleep out and display on with some delays in-between is enough to get the display to work, I figured using some of the power control, vcom and gamma control commands from the available libraries (e.g. Tilen Majerle) seems to improve the picture quality. Then again, the documentation in the ILI9341 datasheet regarding power control, vcom settings etc. is pretty meaningless.Like it tells you that you can set a voltage to 4.5V but it doesn't tell you under which circumstances you would want to do this.Does anybody have a good understanding of what values to configure why for power control A/B/1/2 and VCOM 1/2?BTW2: since a series resistor is usually needed for other display backlights and the current draw looked pretty high (like 180mA @3.3V), I tried a 10Ohm resistor for the backlight. This reduces the current draw to about 79mA while the backlight is still pretty bright. As the board comes without any documentation: any ideas about the necessity for a series resistor?

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 13, 2015, 07:35:04 pm
content: Ok, it started freezing again with a nearby phone, so I could continue to investigate.I found that the display is not really dead, but simply entered sleep mode on its own.I.e. it reports 0x0C on the Display Power Mode command (0x0a) instead of the usual value 0x9c.I take this as Display is On, Display Normal Mode On but Sleep In Mode and Booster Off or has a fault.Performing a full reset seems to cure this. Maybe/probably I don't even need all the original init steps,but it's a bit of a drag to investigate as it only happens now and then.Besides, I'm still puzzled what happens there exactly.Either it receives a sleep command through noise on the SPI or D/CX line or it's really something internal that let's the boost voltage break down.

author: kjs
author_rank: Regular Contributor
timestamp: March 13, 2015, 07:43:37 pm
content: My guess is that the RF enters the boost converter and gets rectified somewhere which causes that thing to stop. Not uncommon with the pretty strong signals you have with a close by phone.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 13, 2015, 08:42:32 pm
content: This probably makes sense. I assume noise on the SPI communication would create a lot of different issues like garbage in the pixel data.The issue however is always the display entering sleep mode.Anyway I implemented the following workaround for robustness:1) Every second, read power mode (0x0a) and check if it's 0x9c2) If not, wait 60ms, send Sleep Out command (0x11), wait 60ms.There is space left for fine tuning like optimizing the delays or checking explicitly for sleep mode and performing a SW reset in other unexpected cases.But this simple approach seems to work reliably and fast for the only case I observe. I had 6 successful recoveries in the last 15 minutes or so.