 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Corrupted 1963 LCD display....
  Page 2 of 3   |
|||||
| Author | Message | ||||
bigmik Guru  Joined: 20/06/2011 Location: AustraliaPosts: 2971 |
Lads, Has anyone tried putting a 100nf (trial and error) cap between GND and the WR clock pin? Kind Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1964 |
Wish it was that easy, a cap would shorten the pulse by rolling off the leading edge, 100n would virtually bypass the pulse to ground. I tried a big bypass cap on the 3.3v rail and measured the rail in operation, no difference and the rail is solid. Big difference in length of the LCD drive cable, it's much longer on the 5" and the processor is closer to the pins on the 7", both would give the 7" an advantage at higher clock rates. But as posted previously, some have no problems with the 5"- IDK? NANO Inverter: Full download - Only Hex Ver 8.1Ks |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
Well shut my mouth!  That makes no sence at all then, using my logic - best to ignore my attempts to explain it away saying slowing down the MM clock slows down the I/O!   Smoke makes things work. When the smoke gets out, it stops! |
||||
GoodToGo! Senior Member  Joined: 23/04/2017 Location: AustraliaPosts: 188 |
Revisiting this as my newly acquired 5” display is having corruption issues as well. It’s also connected to an Explore 100, and I’m finding that the console display on lcd is dropping characters. Dropping the speed to 80MHz of course cures it. So did anyone come up with a complete 100% cure? Has anyone modified the driver to include a few NOP’s as Matherp and Robert.rozee have suggested? Cheers, GTG!  ...... Don't worry mate, it'll be GoodToGo! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
I cannot get this problem to show up on my prototypes so I will need your help here. Try the attached firmware (Micromite_Plus_V5.04.09_Beta_1.hex). In it I have placed strategic NOP's which might do the trick. Let me know if it does or does not work. If it does not fix the problem I can try another approach. 2017-12-31_114942_Micromite_Plus_V5.04.09_Beta_1.hex.zip This version is about 35% slower in writing to the screen so, if it does work, we will need yet another option to turn it off/on so that other users do not also experience a slow down. Geoff Geoff Graham - http://geoffg.net |
||||
| GoodToGo! Senior Member Joined: 23/04/2017 Location: AustraliaPosts: 188 |
Howdy Geoff, The Beta works perfectly! I no longer have any screen corruption either using the 5" display as the console or with a running program!  Hopefully others will also try it out to see if it fixes their screen corruption issues. Not sure if you want to fine tune the beta to minimise the slowdown, but I'm more than happy to be a guinea pig. Cheers! GTG! ...... Don't worry mate, it'll be GoodToGo! |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Good news and thanks for offering to be a guinea pig. Both the below versions run faster than the previous but they implement the delay in slightly different ways. I would be interested if they work in your setup. My money is on Beta 1b as that stretches the write pulse. 2018-01-01_092112_Micromite_Plus_V5.04.09_Beta_1a.zip 2018-01-01_092139_Micromite_Plus_V5.04.09_Beta_1b.zip Thanks again for your help, Geoff Geoff Graham - http://geoffg.net |
||||
| GoodToGo! Senior Member Joined: 23/04/2017 Location: AustraliaPosts: 188 |
Happy New Year! The corruption returned in Beta 1a. No corruption in Beta 1b. Your money is safe. It's good to see the screen working as it's supposed to! Cheers, GTG! ...... Don't worry mate, it'll be GoodToGo! |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Thanks. Give me a day or two and I will come up with a version that can compensate for this issue, possibly via yet another option. Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
This is a stable beta of V5.04.09 which should fix the corrupt display issue for everyone. It generates a write pulse which is double the width used in V5.04.08 but there is not a performance penalty because of other optimisations with writing to the SSD1963. Because of this an option is not required to invoke this fix 2018-01-02_112032_Micromite_Plus_V5.04.09_Beta_2.zip Please let me know if you (or anyone) has a corruption issue with this. Thanks, Geoff Geoff Graham - http://geoffg.net |
||||
| GoodToGo! Senior Member Joined: 23/04/2017 Location: AustraliaPosts: 188 |
Works well Geoff! All corruption I was experiencing in the console on the display or in a running program has disappeared! Thanks again for all your efforts! Cheers! GTG! ...... Don't worry mate, it'll be GoodToGo! |
||||
jman Guru Joined: 12/06/2011 Location: New ZealandPosts: 711 |
Hi Geoff I can also confirm the beta 2 works great with my 5" display. This display was real fussy and required the power supply modifactions suggested by matherp to get to a usable state but now its 100% Thanks for all the effort Regards Jman |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
Just curious - so was the WR pulse too narrow and the 1963 controller was missing it? Smoke makes things work. When the smoke gets out, it stops! |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Yes Grogs, the SSD1963 latches the data on the trailing edge of the WR signal. The pulse width used in the original firmware was within specs but I suspect that stray capacitance reduced the rise/fall time on the WR line so that the SSD1963 saw a narrow pulse that was outside of its specs. With such a narrow pulse it probably missed the trailing edge, especially with noise on the ground pin, flaky Vcc, etc. We are talking just a few nanoseconds here so it would not take much. Do you have any problematic boards to test this on? Geoff Geoff Graham - http://geoffg.net |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
Interesting. Thanks for that information.  When you considder the frequencies in use on the E100, it is a bloody miracle in some respects, that everything works as it should! By that I mean that once you get up into the clock pulse frequencies we are using on this board, you GENERALLY need to be very careful with PCB layout. We weren't, really, other then making the top copper GP and bottom copper GP both ground to help sheild the signals somewhat. I DID have some problematic boards, but they have all been on-sold complete with LCD as part of systems. I just slowed the CPU down to 80MHz, and the problem went away. QUESTION: If 80MHz actually runs the clock FASTER then at 100MHz(reference: matherp), how do the displays behave at 80MHz when the clock is technically FASTER then it is at CPU 100 or CPU 120?  .....scratching head......Smoke makes things work. When the smoke gets out, it stops! |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Peter may have got it a little wrong. Yes the peripheral clock is faster at 80MHz but the digital output function of an I/O pin is clocked by the CPU clock which is faster at 100MHz than 80MHz (obviously). Essentially, switching to 80MHz (from 100MHz) made the WR pulse longer by 20% - which shows just how close the tolerances were and that the original timing at 100MHz was marginal (let alone at 120MHz). Beta 2 has doubled the width of the WR pulse so it is no longer marginal at any CPU speed. Geoff Geoff Graham - http://geoffg.net |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4147 |
Do the number of wait states (WS) change as those clock speeds change? If yes, does that affect the pulse width(s)? John |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10598 |
Sorry but not right. If you look at page 137 of the MX470 manual you can see that the data is clocked into the output latch by the peripheral clock pbclk which is faster at 80MHz CPU clock speed than at 100MHz (50MHz). HOWEVER it may well be that the chips internal firmware is imposing some sort of wait state at CPU clock speed after a write to the output register to allow time for pbclk to "catch up". Otherwise in the limiting case given a CPU speed twice the peripheral clock speed (or an even greater multiple) it could theoretically be possible for a write of 1 and then 0 in consecutive instructions to be missed completely by the latch. Of course I may be just misreading the datasheet as usual but I suspect there is something going on in the silicon implementation that isn't really covered in the datasheet. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
You are right, I was looking at the PIC32 family reference manual (section 12) which is obviously out of date. I think that you are right in saying that something is going on behind the scenes, looking on an oscilloscope the WR pulse width does seem to vary according to the system clock (higher frequency = shorter pulse) however the exact relationship is impossible to pick out using my 100MHz instrument. Geoff Graham - http://geoffg.net |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4147 |
Some sort of sync between (*) cpu clk and pbclk but bear in mind wait states (which as I understand it rather dimly may increase as cpu clk does). (*) things controlled by I think maybe Mchp make it hard to fully understand this. The PIC32 is mostly really well doc'ed but this part? Did I miss it, where is it properly described? Feels like a small number (**) of individually free running synchronous state machines which sync rather well when they have to but somehow the doc is a bit lacking. (**) I'd like to say 2 John |
||||
| Page 2 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
