We have a problem related to colors, first time we notice it it was not very easy to spot, but with a gradient grayscale image, appears as distinguished stripes. We made some other specific tests, including RGB individual gradient of primary and secondary color (single primary colors and combination of two primary colors), we we notice that only colors that contain blue have the stripes. We simulated the bit color error from PC software and found the matching color pattern resulted from bit 3 being fixed, either always low or always high all the time, regardless of the image. We verified the carrier and that was not having any short or open connection to blue bit 3. Then we put the osciloscope to Colibri board pin documeted for blue color of bit 3 and verified that indeed, bit 3 of blue is always high and never changing, regardless of image on the screen.
Anyone had the same problem?
Is it possible that Toradex’s specs to be wrong regarding pin number of blue bit 3?
I have multiple Toradex board, both V1.0A and V1.1A, with the same issue. If we change the 18/24 bit of color, the bit 3 of blue remains high all the time.
I will attach one image from display picture, and another image with the simulated color strip screenshot which matches. The image has the problem on bit 5 of blue, because the picture and screenshot shows the problem for 18 bit configuration, however, for 24 bit configuration, bit 3 of blue is with the problem, and that was what we verified on out Colibri board as always high level.
Any help is appreciated, Thanks
link text
Can you please post your display configuration registry entries here?
You may also use the GPIO tool to check that the pin is configured for the right alternate function:
It is in our standard image, but can be changed by configuration or by other apps/drivers running on your system.
Dear @core
Can you please share the partial schematics (or netlist / table), how your displa data signals are wired to the Colibri module? I would like to see which SODIMM pin you are exactly referring to with the term blue bit 3.
Regards, Andy
You are right! For some reason the pin 58, used by bit 3 of blue was set to output high. I guess, there is some feature in our OS design that make this setting, I need to indentify it now.
If I changed the function to display function, I can see the blue gradient without strips. Thank you!
I attached the current settings from GPIOTool, which shows the missing DISP 3 bit, while sorting, and the actual function, as GPIO.link text
Is there a way to make sure display pins are correctly assigned from OS design? I tried to find any pin related settings, and there are only a few, in the registry:
“BL_GPIO”=dword:0000003A
There is another one in the specs, which we do not use: DISP_GPIO.
0x3A is actually 58 that seems to be the pin having the issue. You configured it as backlight-enabling pin, and the driver then uses it as a GPIO.
That is probably the problem, thank you. We had some older display registry settings that we used to have before our custom carrier, the current backlight is not actually used by pin 58, and we control it by PWM. Thank again!
There is one more thing. I removed that registry entry from my custom OS design, then after I write it to Colibri module and I did the registry clearing operation, I still see BL_GPIO with a very high value of 2147483738 (0x8000005A), in the clean registry. Is this normal behavior? Shouldn’t be missing entirely or that is a default value? The blue color has been fixed on both 24 and 18 bit color carrier board, so this setting was affecting both.
bit 31 set means that this is a GPIO number (processor GPIO) and not and SO-DIMM (connector) pin number.
What version of our BSP are you using, if I remember correctly we remove that setting some time ago.
We used BSP 1.1 for our custom OS design.
This is quite an old version. We just release 1.4b4 and plan to move this to 1.4 release by the end of the year, there are lots of improvements and bugfixes so you may consider updating your design.
We measured a significant performance decrease with 1.2x and 1.3x versions, at that time we decided to use 1.1, and the reason for performance penalty, you guys said, to be from a dual display enhancements that force you to disable some graphics accleration. Have you fixed that?
In version 1.4b4 2D graphics acceleration is enabled, that should bring back same performances as 1.1.
If you still see issues, having a small application that allow us to reproduce them would help trying to fix it.