This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi, Crisler,
It is very strange you cannot see the menu box I attached in the thread. Could you check with if there is any other buttons like "Edit more" you can try to see if the menu box can display? Or could you check your explorer version? Maybe changed to IE explorer or Google Chrome?
For the LCD 8 mux contrast question, the contrast should be poor theoretically for 8 mux @ 1/3 bias mode. 8 mux @ 1/4 bias LCD will be much better for the contrast.
Thanks,
Lixin
Hi, Crisler,
Do you have any update for for this? Do you have resolved the file attaching issue?
Regards,
Lixin
Hello Garret,
It seems you have your default editor set to Plain Text instead of Enhanced. To change this, click your Profile Icon on the top right of your screen. Click Settings and it will open up another page. From here find Content Editor on the page and hit the radio button for Enhanced, then save the settings. You may need to log out and back into E2E to see this change.
Okay that worked on getting the editor working. Not sure how it got set to Plain mode.
Here is the photo of the display and oscope. The scope is 1 v/div. The display charge pump is at 3.2 v, I have adjusted it from 2.6 up to 3.4 volts. I am thinking the ghosting is caused by the driver not being able to adjust the steps quick enough.
Hi Garret,
your wiring looks good mechanically when taking such a ribbon cable. Electrically however it causes the reflections you can see.
Our LCD drivers have high impedance outputs, meant to be interfaced to the LCD display not far away from the device ...3-4" and connected using traces that are not backed with a ground plane on the PCB to reduce the stray cap towards ground... and to keep the apparent impedance as high as possible. The standard ribbon cables have a differential impedance of about 100 Ohms. And that when no guard ground is used, elsewise lower.
What you can see on the scope are the reflections caused by the cabling. Tearing the ribbon cable apart should improve the situation. But a long cable is still not optimal...
Transmission line theory is the key element here; it causes funny effects sometimes...
have a nice day,
Johann
Well none of the above answer is applicable. The MSP430FR6043 is mounted directly backside of the LCD. The ribbon cable is simply being used for programming and supplying power. I also tried running the display directly from a battery. No difference. I have also produced several of the same boards and they all act identical, so it isn't my soldering or random bad chip or display. The other issue is that I cant mount external resistors to produce the bias voltage as these pins are used as the LCD display COM lines on this chip.
Hi, Garret,
Do you have found the root cause of the glitch on LCD signals? Maybe adding a pF capacitor at the end of LCD signal can help.
For the ghosting, could you try to increase the frame frequency? Normally, higher frame frequency can help to reduce the ghosting but may not eliminate all.
Best Regards,
Lixin
I have built a driver board using a msp430fr4133 which uses the LCD_E module. It works perfect. No ghosting, good contrast. So I know that it isn't the display. Is the LCD_C module robust or was it replaced for the reasons that I am experiencing?? It seems strange that the LCD_C module was utilized on a new chip (msp30fr6043) . The LCD_E seems superior in every way.
I am happy you found LCD_E can resolve your issue.
LCD_E is different from LCD_C. For example, LCD_E needs more external pins - 0.1uF on LCDCAP1 and LCDCAP2. LCD_C support 1/2 bias. LCD_E has bigger driver strength. For details, please refer to application report http://www.ti.com/lit/an/slaa654a/slaa654a.pdf .
For your test result, do you have compare the settings for both cases, frame frequency, LCD voltage setting, charge pump voltage, etc? Maybe LCD_C can also work well if adjusting some settings.
Regards,
Lixin
I have experimented with all the settings. I am having the display remade to 5 mux so I can then access the R03, R13, R23 to either produce a suitable resistor ladder or try hanging capacitors on those pins.
I also noticed the EVM-6047 uses an external resistor ladder instead of the built in ladder. When I was designing my board I wondered why they didn't use the internal ladder, seems much simpler. Seems plausible that your people also couldn't get it to work satisfactorily. If that's the case it would have been nice if that was in the literature as this has set me back a couple of months try to get this to work.
The LCD_E seems superior in every way.
Why was the LCD_C driver chosen for the MSP430FR6043 chip which is only about a year old?
Does the LCD_C driver have some advantages that I am over looking??
Thanks for the information. It seems you have tried the experiments with different settings. Yes, LCD_E is later design after LCD_C. It has better driven strength. But we haven't compare the performance between them for 8COM LCD driving.
I haven't seen any errata bug for LCD_C. The internal resistor ladder can be used in MSP430FR6047/6043. But the resistor ladder resistor is about 10k-ohm for each (there are 4 10k-ohm resistors in the ladder). This will cause bigger current when LCD is displayed. To save power consumption, we can use external resistor ladder with bigger resistor value. This is why MSP430FR6047 EVM design the external resistor ladder - 4x 330k-ohm resistors.
Q1: Why was the LCD_C driver chosen for the MSP430FR6043 chip which is only about a year old?
This is to keep consistent with MS430FR6047 because they are all for USS applications. It is for easy code migration.
Q2: Does the LCD_C driver have some advantages that I am over looking??
No. LCD_C can save pin usage than LCD_E and LCD_C has internal resistor ladder for bias generating. Its design is different from LCD_E. LCD_E has its own differentiate features: flexible segment/com pin configuration to ease layout, support LPM3.5, higher driver strength, etc. But if the application needs more GPIO pins, LCD_C can help.
Hope my answer can help you.
Best regards,
Lixin
**Attention** This is a public forum