This would be really great to know yes, it would be so great if we could fix this ourselves (fine soldering is not a problem) or if we can just order a new board without having to get a whole new display.
I wish the foundation wasn't so tight-lipped about things like this.. It's not like they need the secrecy to maximise profits, they're only a non-profit foundation. Just tell us the truth please.
Even the schematic would help (it's supposed to be open source after all). Though I have a feeling the 'bug' is in the firmware of the microcontroller on the board rather than an actual wiring fault. Or perhaps the display backlight is wired to a microcontroller pin that doesn't support PWM?
Edit: I wonder which chip it is, I'll have a quick look, gordon did mention at one stage that it was a microcontroller they were using for PWM so the markings should identify the possible candidates.
Edit2: Ok, U6 is an Atmel Tiny88 which is the most likely candidate for the PWM. The chip on the flex-PCB is a touchpanel controller so that's not it (good, because that would mean replacing the display in any case). That means that a new controller board should fix it (after all, the wiring of the backlight on the display itself is good, otherwise it wouldn't be able to turn it on and off).
If it's a wrong pin on the Tiny88 it shouldn't be too hard to make a fix though it will require some VERY fine soldering, it's a QFN32 package as far as I can see. That means the pins are 0.5mm apart. Still, I've done it before (with Kynar wire it's doable). It'd probably require making a bridge with a single wire from one of the pins of U6 to somewhere else on the board.
But if the error is in the firmware, updating the Tiny88 firmware in situ would be pretty tough as I see it.. I see some test points but I don't think they're ICSP points for the atmel. We'd also have to actually *have* the new firmware binary of course, and solder multiple wires to U6 to connect to the ICSP programmer (which would be needed too), possibly some pins positioned side by side so no room for error. Still, if I'd have the firmware file I'd totally try it
Of course it could also be a combination of both: requiring a bridge to a new pin that supports PWM, and an update of the firmware to use this pin and the PWM functionality. It's hard to say without more information.
Edit3: I just had a look at the tiny88 document and I see the port that's usually used for PWM is OC1A, pin 13.
Though it's a bit strange that this 32-pin chip seems to have only 1 PWM whereas the 8-pin tiny85 has 2. But this one seems to be super featured with phase and frequency selection besides the usual duty cycles etc.
Anyway this pin 13 is probably the right one, as all the references to PWM mention this pin. On my 1.0 board there's a trace connected to it leading to a 33 ohm resistor (R1), transistor (Q1) and then another via which I presume connects to the big flatflex connector J7. It goes underneath it so I can't follow it there. I also couldn't visually confirm the trace end to end as it was going under J7 before even going the transistor but it checked out with an ohmmeter.
So this looks like it is properly configured to drive the display with PWM (the transistor being there to switch the actual power to the backlight, the tiny88 couldn't drive this much current). So at the moment my best guess is indeed a firmware issue in the Tiny88. As they only started implenting this feature after the boards were shipped, it may have been an oversight in the code.
If anyone has the V1.1 version, could they please take a highres closeup photo of the PCB traces around U6 and especially the one leading up to the little via (little circle where the trace goes through to the other side) underneath the touch panel connector J4?
A comparison would probably reveal some information as to what has changed (and if nothing has, it would pretty much confirm a firmware issue)
Edit4: I just thought of something: if a board or firmware fix on the Tiny88 proves impossible, perhaps it would be possible to wire the raspberry's PWM pin into the backlight transistor. I don't see why not, but it wouldn't be ideal as you'd lose the built-in operating system control under /sys/class/backlight. It would have to be controlled with some custom code. And worse, that raspberry pin is shared with the audio out so that couldn't be used then. An external micro is also an option but even messier. I'll have a look at the pi's pwm pin idea tomorrow.
PS: Sorry for digging so deep into this but as a maker I don't like taking 'no' for an answer
If there's any way to fix it I'd rather do that than buying a new board.
