LCD flicker about t-962-improvements HOT 17 CLOSED

You're most welcome, thanks for trying it out!

That looks like the data is clocked out a bit too fast for the display.
I am very close to the limit and your display may be a slow one.

The easiest way to test this theory is to increase the BusyWait8 times
around the E toggle in lcd.c a bit (LCD_WriteCmd and LCD_WriteData
functions). The data sheet says that a 1MHz clock should be fine (so
500ns high/500ns low plus overhead should be plenty), but these
knock-off chips may be a bit marginal. Most likely the original firmware
runs it a lot slower. For performance reasons as there's no way to
accelerate the output I want the cycle time to be as short as possible,
so hopefully 13, 14 or 15 should work with your display. I have
rewritten the whole BusyWait and timing stuff but it needs a few more
hours of work before it's ready for prime-time, so hopefully tomorrow.

If you have values that works I can definitely adjust the timing, it
will be interesting to see how far off your display really is.

By the way, your XTAL is a 11.0592MHz one, right?? Just checking!

from t-962-improvements.

Oh, another "by-the-way": Did the code detect the correct LPC part (and which one was it)? If you feel like updating the tested configurations WIki page I most definitely wouldn't mind, otherwise you can just put the info in here if you want and we'll figure it out! :) Thanks in advance!

from t-962-improvements.

Wow that was a fast reply, thanks!
I sounds like a good idea to check the lcd timing, I will have a look at this later today and return to you.
regards,
Fredrik

from t-962-improvements.

To answer some questions, part is LPC2134(/01) Rev E according to startup screen
and yes, XTAL is 11.0592MHz...really hard to read it though.

from t-962-improvements.

Ok ,some more info
I rebuilt the sw with BusyWait8(10) and BusyWait(15) in LCD_WriteCmd and LCD_WriteData.
15 worked but 10 did not.
I will test other values tomorrow (11-14)
At least now we know that you were right about the timing....great!

from t-962-improvements.

Hmm, obviously I was a bit tired late last night, the delay was talking about was supposed to be "4", not "12" which should have translated to 0.5us. If not even 10 worked for you but 15 did that means that the timing is off by more than a bit. It would be interesting to know the very lowest number that actually works for you (then we have to add a tick or so for margin).

Is reflow cycle timing correct (as in seconds of runtime actually being realtime)? Just wanting to make sure that I haven't hit some obscure bug in rev E of the LPC that would throw all timing off (I'm using rev F of the same chip).

Also, if you have the possibility to scope out the E and D0 pins of your display (that should be pin 6 and 7 respectively) so we can see if there's insufficient setup time, and also the true speed of switching. Maybe there's just too much capacitive load on the pins.

from t-962-improvements.

Yeah I thought is was a bit strange that the value would go from 4 to 12...I will check the timing of the signals tomorrow and return to you.

from t-962-improvements.

Awesome! Yeah, the onewire stuff uses 1.5us timing - confusing.. :)

from t-962-improvements.

I have updated a bunch of stuff now including timing, so the LCD timing now actually specifies 0.5us, not 4 ticks. It would be interesting to see how much you have to increase it to get a stable display in your oven!

from t-962-improvements.

Ok great...I will download and test later today

from t-962-improvements.

Some updates.
I downloaded the latest src and tested with some different values, from 0.5 and upwards,
The first value that seemd to work was 2.0!..I haven't tested a lot of different values, but 1 did not work. IF you want me to test values between 1 and 2 I could of course do that.
I also measured the timing on E and D0 as suggested above. Se attatched image.
https://dl.dropboxusercontent.com/u/74192107/20140510_145151.jpg

from t-962-improvements.

Also, I ran a complete reflow sequence and checked the timing, I think it is spot on, no problem there.
Another thing I have been thinking about though....How do I know that the DS18B20 sensor is working properly? Is there any way to see this in the display. The temperature values shown seems reasonable accurate but maybe they can be quite right even if no values are received over the 1-wire bus?

from t-962-improvements.

So I just committed a rework of the low-level LCD stuff to master. After
paying closer attention to the datasheet it was obvious that I forgot to
check the BUSY flag of the controllers - interestingly my display had no
issues whatsoever. I haven't dealt with these brain-dead controllers in
a long time. :/

Turns out that some commands takes a while to execute, but data tends to
be really fast, so you should see a very small increase in time spend
refreshing the display. On my display a normal update takes 2.5ms. 16
command bytes, 1024 data bytes and 16*2+1024 busy checks (busy is
checked on both controllers for commands) = 2096 cycles gives an
effective E frequency of just over 838kHz which isn't too bad taking the
1MHz maximum frequency into account.

Thanks for the scope trace, that at least verified that the signals
looked sane and the issue had to be elsewhere! I scoped the RW output of
the original firmware and did not notice any toggling of the RW line, so
they must just clock slower than necessary.

What I hope is that this code will solve your display issues! Please
test and if this solves the issue we should be able to close it!

Good to hear that the timing in general seems to be right at least!

from t-962-improvements.

Hmm, I should put the Cold junction readout back in bake-mode - that
will give you an indication. It will be hard-coded to 25C if no 1-wire
device is found. Can you check the UART output for now? The code will
output the CJ temp 4 times per second and also enumerate all devices
found on the bus, like this:

Initializing improved reflow oven...
Running on an LPC2134(/01) rev F
Buzzer_Init
ADC_Init called
OneWire_Init called
Scanning 1-wire bus...
Found 23000005e771cb28 [Temperature sensor]
Found cc000000186e8e3b [Thermocouple interface, ID 2]
Found 49000000186e893b [Thermocouple interface, ID 0]
Found 95000000186e8d3b [Thermocouple interface, ID 1]
Found 27000000186e8b3b [Thermocouple interface, ID 3]
TC0= 0.0C TC1= 0.0C TC2= 0.0C TC3= 0.0C CJ= 0.0C Setpoint= 30C
Actual= 0.0C Heat=0x00 Fan=0x00 Mode=STANDBY
TC0= 23.0C TC1= 23.8C TC2= 22.8C TC3= 22.5C CJ= 23.8C Setpoint= 30C
Actual= 23.4C Heat=0x00 Fan=0xff Mode=STANDBY

(so my setup is a bit redundant as I have both the temp sensor and TC
interfaces with built-in CJ compensation, but I want to be able to test
all the code paths)

from t-962-improvements.

Ah great!
I will test the new fw when I get home!

from t-962-improvements.

I tested the new fw yesterday and it worked! Great!

Unfourtionately I can not see the serial output. I installed a ftdi breakout permanently in the oven and also connected the control signals for reset and bootload. When I connect to the chip the oven reboots into bootload mode it seems.

from t-962-improvements.

Great to hear that the display works! If you want to get to the serial output you need to tell the terminal program not to raise RTS and DTR (most should be able to do that). Remember that the default bitrate of the logging output is 2Mbps (which the FTDI chip should deal with just fine). I did add the cold-junction readout to bake mode UI so no need for serial just to check that though. Closing this LCD issue, thanks for checking!!

from t-962-improvements.