I’ve a couple of related questions about eboot timings:
Are there any circumstances where the splash screen image is not output on the parallel RGB interface until after the configured dispondelay?
If you configure the eboot configblock to turn on various GPIO pins in both the gpio block and the splash screen block (via the BL_GPIO and DISP_GPIO settings), is there a fixed deterministic order that the GPIO pins will be enabled? Or are the different config block settings applied asynchronously?
The background to the query is we are looking at using a different TFT LCD display with our Colibri T20s, previously we used a display that had a parallel RGB input but we are looking at using a different display which has a LVDS input with a TI DS90C383 to do the signal conversion.
This all works fine apart from we get a very brief (a few tens of milliseconds) flash of a random colour before the splash screen is shown – the colour changes each time and fills the whole screen. We do not control the display’s enabled signal but have two signals that control the backlight and when the backlight is off the display cannot be seen.
We have tried the obvious things of setting the ss.bl_gpio and disp_gpio to control the backlight signals and varying the dispondelay (up to several seconds), but all that happens is the coloured flash and splash screen are displayed later - after the dispondelay period. We have also tried all the combinations of pins to bl_gpio/disp_gpio, and all eboot versions from v2.0 to v2.3, without any success, and have done various hardware scoping. We do use a custom splash screen and WinCE 7 image (but standard eboot), but the issue also happens if I just use the standard Toradex flash image (v2.3 loading using the .cfg file) with the splash screen configblock updated to match the display timings and bl_gpio/disp_gpio.
However, if we configure the backlight signals to be set by the gpio config block then we don’t get the coloured flash. This is making us wonder if we have somehow caused the splash screen to not be output to the parallel RGB output until the dispondelay period and if so whether a workaround might be that we can reliably rely on some of the gpio settings being applied at a reasonably constant point.
Dear @prmartin
We’re looking into the issue. To get some more understanding, can you please tell me how you connected the DS90C383’s nPWR_DOWN signal?
Regards, Andy
The splashscreen is always output only to the parallel LCD interface.
I currently have no explanation what happens in your system. I verified that delaying the DISP_GPIO works as expected. Please look at the two scope measurements below:
CH1 (yellow) = 3.3V power rail
CH2 (cyan) = VSYNC, showing that the pixel data is clocked out
CH3 (magenta) = GPIO T4 = DISP_GPIO
The left picture shows the default ss configuration( ss.dispondelay=0),
the right image shows the signals with ss.dispondelay=500
It clearly shows that GPIO T4 is turned on only after the waiting period of 500ms. If you use this GPIO to turn on your backlight (and don’t use it for anything else), I don’t see a reason for the color flash.
Any display I know has an electrical independent backlight, so turning this on should have no side effect.
I recommend to check whether GPIO T4 is used for anything else in your circuit. If not, then it might be an EMC issue - turning on the backlight leads to a high surge current, which lets the display flash?
Can you confirm that you see the same scope pictures as I do?
We use GPIO B5 for the backlight enable (with GPIO U3 controlling “high brightness”), nothing else is using them apart from our application changes them to be PWM outputs to give us fine control of the brightness. We have also tried changing the GPIO for the backlight enable to T7 as an experiment, without any change.
We did consider that it might be a high surge current when turning on the backlights, but the fact that there is no flash if we turn on the backlight using the gpio configblock instead would suggest not, and we couldn’t see anything when we scoped the power supplies.
I haven’t scoped VSYNC yet, I will do that now.
Previously we’ve scoped other pins either side of the DS90C383 -the DISP_GPIO signal was showing exactly the same trace as you got, but the parallel RGB was showing a constant value and the LVDS signal a fixed pattern from shortly after power on until about 15ms AFTER the DISP_GPIO signal went high at which point both RGB and LVDS signals started varying as we would be expected.
I think we are searching in the wrong corner (or maybe I didn’t understand your setup and tests correctly). Look at the system from a viewpoint of the display - the display does not matter whether the input signals are coming from a Colibri, a PC, or anything else:
These are the input signals as your display sees them (if I got you correct)
The backlight is just a lamp. The LVDS display behaves exactly the same whether this lamp is on or off. Only if the lamp is off, you cannot see what’s going on.
I assume the following happens while booting:
There’s three events in the power-up cycle of the display:
The 3.3V is turned on
The LVDS-Signals start to toggle correctly
The Backlight is turned on
In worst case +3.3V and LVDS-Signals could turn on in any order, even mulitple times due to some bouncing. During this phase the display is not yet properly synchronized to the LVDS-Signals and as a result generates a colored flash for the duration of a few frames (10-100ms).
This flash may happen or not. However, I think this is not relevant. After the flash is over, the display outputs a stable image.
If BL(PWM) is turned on early enough, the flash is visible.
If BL(PWM) is turned on after the flash is over, all you will ever see is a stable picture.
Again this is all independent of the Colibri, or any software configuration, I’m just describing the behavior of the display itself.
Detail Notes
This is to follow-up your previous comments. However, I suggest we follow up on the Next Steps only (See below).
Whether you measure VSYNC or any other RGB/LVDS signal is not really relevant. I have chosen VSYNC simply because it is the slowest signal indicating that the Colibri is outputting display data.
The Colibri will output stable display data starting at latest at the 2nd VSYNC pulse. The LVDS transmitter and receiver might require another one or two frames (=VSYNC pulses) to properly synchronize, so after no more than 3 VSYNC pulses I expect the communication to be perfectly stable.
Next Steps
To prove that my assumption about BL(PWM) being independent, can you control the BL(PWM) signal in hardware (decouple it from the colibri and use some jumper wire to turn the Backlight on)?
Try turning it on together with +3.3V (so you will see the flash), and in another test turn it on after some 5 seconds (so you will see no flash).
If there are any additional control or power signals going to the display, can you please explain the details about this?
I still am pretty sure that the backlight timing alone cannot explain the behavior, therefore I need to better understand your hardware setup.
You assumption about the BL(PWM) being independent is completely correct. Connecting the backlight to be powered from an external supply:
If I have the backlight always on then I get the full coloured screen for about ~1 second after 3V3 goes up until dispondelay (e.g. with disondelay set to 5000 I gets about 4 seconds of colour, with dispondelay set to 200 I get a brief flash).
If I turn the backlight on after around 5 seconds I get no flash.
Given what we are visibly seeing and what we see on the scope it feels like it is something in the way we are driving the TI DS90C383. I’ll drop a private message with the relevant part of the schematic.
Dear @andy.tx ,
Thanks for looking through the schematic.
I will scope the signals you suggest and check the timings, there will be a few milliseconds delay on various of the power supplies to satisfy the power on requirements of the display.
I’d be surprised if RST-TFT# is the culprit, unless there is some interaction on the T20 between GPIO B5 when set by ss.disp_gpio and GPIO I4 which controls RST-TFT#
I will verify it though as we haven’t check it yet.
I’ll send the backlight schematic across in a private message (sorry I had removed it from the page as we had discounted it in the analysis)
Just as a mild clarification, we are not actively controlling GPIO I4 (and so RST-TFT#) ourselves so I presume it will be in the default function of being nRESET_OUT.
Dear @prmartin
Ok, I didn’t have this part of the schematics.
If C-RSTO# is connected to SODIMM 87 (RESET_OUT#), it cannot explain the behavior. The RESET_OUT# timing is fixed and is not effected by the ss.dispondelay setting.
Regards, Andy
Unfortunately I still couldn’t find any bootloader configurations which would achieve a better result than the workaround you are currently using.
However, there might be one more option that could be worth to look at:
In the bootloader, configure the BL_POL inverted to the actual polarity. This will cause the bootloader to turn off the backlight
In the WinCe registry, configure BL_POL to the correct polarity. Make sure that UseSplashSettings=0 is configured.
With this setup, the display will only turn on while WinCe is booting, which is 2-3 seconds after you would see a splashscreen in the bootloader.
At this point, your display is stable for sure, so you would never see the color flashes.
