Hi Aron,
I just updated Hydra to latest firmware included in “NETMF and Gadgeteer Package 2013 R3” and the fix below is not working anymore:
Register LCDCON1 = new Register(0x00500800);
LCDCON1.ToggleBits(0x2000);
The first fix you gave removes the flickering, but still shifts the image:
Register LCDCON1 = new Register(0x00500800);
LCDCON1.ClearBits(0x1FF << 12);
LCDCON1.SetBits(0x1000);
Regards
If I’m doing my math right, you’re pushing the Pixel Clock up to 25 MHz… Aron’s fix shifts it to 16.66 MHz from the default of 7.14 MHz . if you still had flicker at 16.66, I’d try a binary search of clock dividers between 6 and 1. See also the recently revised document at [em]Support>Documents->FEZ Hydra Developer[/em], you want the section [em]Known Issues[/em]
Thanks
Both fixes were given by Aron, but only the one with ToggleBits(0x2000) was usable, because the other one has side effect - the image is wrapped from one side of the screen to the other the moment the fix is executed (with random number of pixels). On other hand that fix now with new firmware still removes the flickering, but sadly it cannot be used because of the image issue.
Any idea why with the previous firmware (4.2.6.0) the ToggleBits(0x2000) fix is working, but with 4.2.6.1 it has no effect? The flicker is same with or without it.
Here is the solution I found.
It is modification of the fix with side effect of wrapping the image. I thought that probably the wrapping is result of changing register content in 2 steps (clearbits and setbits) - there is intermediate wrong register state. So I just combined the steps in a single Write() and it works! No flicker and no image wrapping (restarted the project a lot to make sure that image stays in place).
Register LCDCON1 = new Register(0x00500800);
uint val = LCDCON1.Read();
val &= ~((uint)(0x1FF << 12));
val |= (uint)0x1000;
LCDCON1.Write(val);
@ ovivo - Great you got it working!
@ Gus -
Taking what ovivio suggests (intermediate write of register):
Register LCDCON1 = new Register(0x00500800);
LCDCON1.ClearBits(0x1FF << 12); // <----- HERE
LCDCON1.SetBits(0x1000);
doesn’t work. But
Register LCDCON1 = new Register(0x00500800);
uint val = LCDCON1.Read();
val &= ~((uint)(0x1FF << 12));
val |= (uint)0x1000; LCDCON1.Write(val);
does, is because the first one temporarily results in a clock divider of 2 that pushes the frequency up to 50 MHz. – That value is way outside the range of 25 MHz (which Aron says is the limit for CP7), i.e. the CP7 doesn’t react well to that intermediate over-value?
PS I added max pixel frequency to the Specifications so that we can publish/compare it for all our LCD displays.
I do not believe it is the case 
can you please try the first one that does not work and follow it by a register read?
Then compare it to the second case.
I tested the 3 approaches. At first if was confusing because I read different reg value each time I restarted the project, but I saw that the randomness is only in the MSB bits which are read-only anyway (LINECNT). Only one approach is tested at a time and I restart the project 3 times per approach.
Register LCDCON1 = new Register(0x00500800);
LCDCON1.ToggleBits(0x2000);
Debug.Print("REG VALUE FLICKER=" + LCDCON1.Read());
Results:
REG VALUE FLICKER=952123392
111000110000000100000000000000
REG VALUE FLICKER=920666112
110110111000000100000000000000
REG VALUE FLICKER=945831936
111000011000000100000000000000
Register LCDCON1 = new Register(0x00500800);
LCDCON1.ClearBits(0x1FF << 12);
LCDCON1.SetBits(0x1000);
Debug.Print("REG VALUE NOFLICKER, IMAGE SHIFT=" + LCDCON1.Read());
Results:
REG VALUE NOFLICKER, IMAGE SHIFT=20975616
000001010000000001000000000000
REG VALUE NOFLICKER, IMAGE SHIFT=1004539904
111011111000000001000000000000
REG VALUE NOFLICKER, IMAGE SHIFT=27267072
000001101000000001000000000000
Register LCDCON1 = new Register(0x00500800);
uint val = LCDCON1.Read();
val &= ~((uint)(0x1FF << 12));
val |= (uint)0x1000;
LCDCON1.Write(val);
Debug.Print("REG VALUE OK=" + LCDCON1.Read());
Results:
REG VALUE OK=914362368
110110100000000001000000000000
REG VALUE OK=956305408
111001000000000001000000000000
REG VALUE OK=931139584
110111100000000001000000000000
I think that the 1st approach with toggle bits is not working anymore because maybe the new firmware changed the default value and that toggle results in different value now?
The other 2 approaches don’t rely on previous register value and they still remove the flicker. For both of them I read same CLKVAL from the reg, but the one that directly uses Clear/SetBits shifts the image to the right and all further drawing operations.
Guys, you have been very helpful, I want to ask something unrelated to flicker solutions (for me it’s perfect with the 3rd solution). I searched the forums and could not find info:
2 times when using USB DP power module with a power brick (rated 12v@ 2A) I saw CP7 brightness change at random intervals. It’s different - can be 2-3 times per second or stable for minutes or not happen at all (I cannot reproduce it at the moment). For me it never happened if I use USB power only from PC. So I assumed that this is due to my power brick and continued using USB only.
Now colleagues reported same. They are powering Hydra and CP7 directly through pins 1/2 of socket 9 using custom power supply (pin 1: 3V3, pin 2: 5V (1A), in reality closer to 4.85V). They use different CP7 and Hydra units. Same software is used.
This is power related issue in both cases, right? Any tips?