Missing color resolution WinCE7

andreas · January 20, 2020, 10:05am

Hello

Since we updated our BSP (built by ourselves) from version 1.4 to the latest version 2.3 we have the following problem. Sometimes, as soon as the OS takes over the display, after the bootloader has successfully shown the splashscreen, everything gets a color shift, either in the direction of yellow (blue color weaker) or in the direction of blue (red color weaker). This remains then until the system is powered off.

I used your keycolor picture and recorded the following situations (see attachement):

Situation when everything works normally
Color cast into yellow (with LDDS = 16)
Color cast into yellow (with LDDS = 18)

The difference between LDDS 16 and 18 can be seen on the transition from the bad parts in the key image to the good ones.

It looks like the color resolution of one of the colors gets diminished sometimes. The color shift to blue is very seldom, but the shift to yellow occurs in about 5% of starting the system.

Our splashscreen settings look like that:

ss.fileaddr:    0x0             (FlashAddress with SplashScreen Data)
ss.filesize:    0               (Size of SplashScreen Data)
ss.enable:      1               (Enable SplashScreen)
ss.dbginfo:     0               (Enable DebugInfos)
ss.res:         0x0             (Reserved Flags)
ss.width:       800             (Display Width)
ss.height:      480             (Display Height)
ss.bpp:         16              (BitsPerPixel)
ss.ldds:        18              (LCD Lines Used)
ss.type:        1               (Display Type (0=Passive, 1=Active))
ss.color:       1               (0=Mono, 1=Color)
ss.dual:        0               (0=SinglePanel, 1=DualPanel)
ss.overlay:     0               (Overlay Enable)
ss.dpc:         0               (Double Pixel Clock)
ss.pcp:         0               (Pixel Clock Polarity)
ss.oep:         0               (Output Enable Polarity)
ss.hsp:         0               (Horizontal Sync Polarity)
ss.vsp:         0               (Vertical Sync Polarity)
ss.pclk:        33200000        (PixelClock (in Hz))
ss.hsw:         0               (Horizontal Sync Width)
ss.vsw:         0               (Vertical Sync Width)
ss.blw:         128             (Begin of Line Width)
ss.elw:         128             (End of Line Width)
ss.bfw:         22              (Begin of Frame Width)
ss.efw:         23              (End of Frame Width)
ss.acb:         256             (AC Bias Frequency)
ss.disp_gpio:   44              (Display On/Off Gpio)
ss.bl_gpio:     31              (BackLight On/Off Gpio)
ss.dispondelay: 0               (Display On Delay (ms))
ss.disp_pol:    1               (Display On/Off polarity)
ss.bl_pol:      1               (BackLight On/Off polarity)
ss.pcddiv:      1               (Enable Pixel Clock PreDivider)
ss.res:         0xFC            (Reserved Flags)
ss.bsTeg:       0xF1612030      (LCD Buffer Strength Tegra)

I don’t have any idea what might cause this problem. With the BSP based on version 1.4 everything works without a problem. What could have changed since then that could cause that problem now? It looks like an uninitialized variable which causes the error sometimes and sometimes not.

Thanks for any help.

raja.tx · January 22, 2020, 7:14am

Dear @andreas,

Thank you for contacting the Toardex community!

How did you update the V2.3 image? Did you use .CFG file or only updated eboot and OS?

I am guessing, this would be related to display pins shifting or not configured properly problem.

First, verify the display signals are configured correctly using Gpiotool. If possible, please share your carrier board display section schematic with us. Let me try to verify it.

Did you do any modifications after the update? It seems ss.bsTeg values modified. At the moment we have a bug to change ss.bsTeg through bootloader, hence we recommend you after the program, just modify parameters relevant to your display. Also attached default values for your reference link texthere.

If it is a memory corruption issue that we can confirm with below testing
Do you have a Colibri Eval board? If you have it, connect the VGA monitor and see the color reproduction compare with LCD? Even you can use HDMI feature.
or
Use remote display tool to see the Display frame buffer on PC.

Please share below section registry values using RegEdit export option

The debug steps would help us to solve the issue quickly.

andreas · January 22, 2020, 9:15am

Thanks for your answer.

I update them directly with the newest update tool, but not with the .cfg file.

What I see now with the GPIO-Tool, when I had this color shift to yellow or blue, there were some pins mapped to GPIO instead to the LCD driver.

[upload|UHROD1mwVMIqm+99kYGCP9+ZiEY=]

[upload|lMEPR7KDgjXZCddHREB97OoYWPg=]

Interestingly in both cases pin F4 (LCD_D12) was mapped to the GPIO-unit. In the ‘shift to blue’ case where the red color was missing partly, pin M0 (LCD_D16) was mapped to the GPIO-unit and in the ‘shift to yellow’ case where the blue color was missing partly, pin E4 (LCD_D4) was mapped to the GPIO-unit.

As a workaround I must now explicitly map all needed pins to the LCD driver, but I wonder what changed from BSP version 1.4 to 2.3 that this became a problem.

When I used the remote display tool, of course, I didn’t have this color shift because the problem was not in the framebuffer, but with the wrongly mapped pins.

andreas · January 24, 2020, 6:24am

I can now reproduce the scenario where pin F4 (LCD_D12) gets set as an output instead that it gets connected to the LCD unit.

In the registry I have the entry "UseSplashSettings"=dword:0 and in the configblock I have to set ss.disp_gpio to the actual pin it is connected on our mainboard (pin 44). If I set it to the not connected pin 255, pin F4 is normally connected to the LCD unit.

But e.g. pin E4 (LCD_D4) just gets set to an input randomly. Mostly the problem can be seen when the Colibri gets reset without power loss. I don’t have a solution for that yet.

raja.tx · January 24, 2020, 1:14pm

Dear @andreas,

Could you update the T20 with CFG file and check the LCD_D4 and LCD_D12 default state. If it is LCD alternate functionality retained then I can say there are no problems from the image release then we will look about what changes making the problem.

Just I did a quick test here, LCD_D4 and LCD_D12 settings are correct.

Please let us know if you face any problem with this.

andreas · January 24, 2020, 2:46pm

I flashed now the original Toradex BSP 2.3 (tegra_winceimage_2.3-20190702) with the cfg file using the nvflash.exe (tegra_wincenvflash_2.6-20190506). Then I restarted and set the following settings in the splashscreen section of the configblock:

ss.bl_gpio = 255
ss.disp_gpio= 44
save ss

Restart again and then check with the GPIO-Tool.
Pin F4 (LCD_D12) is again set as output.

Pin E4 (LCD_D4) or pin M0 (LCD_D16) become an input randomly in rare cases during startup, which manly gives the color shift. But the behaviour of pin F4 can be reproduced easily.

Thanks for any help.

andreas · January 27, 2020, 5:34am

I can now understand, why pin F4 gets set as an output when I set ss.disp_gpio = 44. I have to use here as well the numeric representation of the GPIO and not the pin number of the Colibri module. This is not apparent from the documentation of the splash screen settings.

Currently my only option (because of missing time) is to implement a function to force the specific pins to map to the LCD unit, after the display driver has initialized itself.

raja.tx · January 29, 2020, 5:34am

Dear @andres,

Thank you for finding the cause and reporting here.

We have mentioned Set Gpionumber for PXA/Tegra here, don’t use SODIMM number.

Randomly LCD_D16 pin setting to Gpio alternate functionality is not the desired operation.
Just for your safety, you would do force the specific pins to LCD alternate functionality after display launched. But anyway, if you share exact reproducible steps it will help us lot.

andreas · February 28, 2020, 6:07am

Dear @raja.tx

dear @andy.tx

The problem is that it is not very easy to reproduce. I have to switch on and off my instruments many times until I get again into this situation.

Meanwhile, working on an instrument of us where we use also CAN (CToradexSJA1000) I experience the same problem. Sometimes some IOs suddenly get remapped to GPIO instead of remaining at the set GMI-interface.

Initializing the IOs for the GMI-interface looks like that:

// Setup CS Pin 105
// CS4 - K2 (GMI_CS4_N), I0 - GMI_WR_N
SetGPIOAltFn(m_gpioHandle, Txx_K2, L"altfn=2,dir=out");

// Tristate LCD_WR_N (Z3): Multiplexed Pin 99
SetGPIOAltFn(m_gpioHandle, Txx_Z3, L"altfn=-1,dir=in,outmode=tristate");
// Tristate LCD_CS1_N (W0): Multiplexed Pin 93
SetGPIOAltFn(m_gpioHandle, Txx_W0, L"altfn=-1,dir=in,outmode=tristate");

// Enable GMI_WR_N via Tristat buffer set GEN2_I2C_SDA (T6) to 0
SetGPIOAltFn(m_gpioHandle, Txx_T6, L"altfn=-1,dir=out,lvl=0");
SetGPIOAltFn(m_gpioHandle, Txx_T5, L"altfn=-1,dir=out,lvl=0");

// nOE
SetGPIOAltFn(m_gpioHandle, Txx_I1, L"altfn=2,dir=out"); //pin91

// nWR
SetGPIOAltFn(m_gpioHandle, Txx_I0, L"altfn=2,dir=out"); //pin89/pin93/pin99

// Setup Address bit which is used to switch between data and addresses
SetGPIOAltFn(m_gpioHandle, Txx_W6, L"altfn=2,dir=out"); //115 A2
// AD0 -AD7
SetGPIOAltFn(m_gpioHandle, Txx_G0, L"altfn=2,dir=out");
SetGPIOAltFn(m_gpioHandle, Txx_G1, L"altfn=2,dir=out");
SetGPIOAltFn(m_gpioHandle, Txx_G2, L"altfn=2,dir=out");
SetGPIOAltFn(m_gpioHandle, Txx_G3, L"altfn=2,dir=out");
SetGPIOAltFn(m_gpioHandle, Txx_G4, L"altfn=2,dir=out");
SetGPIOAltFn(m_gpioHandle, Txx_G5, L"altfn=2,dir=out");
SetGPIOAltFn(m_gpioHandle, Txx_G6, L"altfn=2,dir=out");
SetGPIOAltFn(m_gpioHandle, Txx_G7, L"altfn=2,dir=out");

// Int
SetGPIOAltFn(m_gpioHandle, Txx_A0, L"altfn=-1,dir=in");

Where the function SetGPIOAltFn looks like that:

void CToradexSJA1000::SetGPIOAltFn(HANDLE hGpio, unsigned int colibriPinNr, const TCHAR *altfnValue)
{
    uIo intPin;
    intPin.ColibriPin.Nr = colibriPinNr;
    intPin.ColibriPin.Tp = ioGpio;
    TegGpio_SetConfigString(hGpio, intPin, NULL, altfnValue, StoreVolatile);
}

When I experienced again the problem, that the communication over CAN was bad, I looked at the IO configuration with the GPIO tool and found that:

Pin G5 gets remapped to the GPIO unit without an action from my side. It seems to be the very same problem like the one I experience with the IOs used for the display. I no longer have any idea what could cause that.

Before we used your BSP 1.4 with its corresponding WinCE updates and everything worked fine. This problems only occurred since I updated to the BSP version 2.3 with its corresponding WinCE updates.

Thanks for any help.

raja.tx · March 3, 2020, 3:28pm

Dear @andreas,

Thank you for your reply. I put a test and could you please for a couple of days and let you know the update.

raja.tx · March 4, 2020, 12:33pm

Dear @andreas,

I did overnight testing yesterday, I didn’t observe incorrect setting alternate functionality problem. I have uploaded the test application here : test application

Could you keep the application(Gpio_Demo.exe) in the USB stick under the AutoRun folder and then connect to the Tegra board.

The application will be launched automatically, after some time, it will print the alternate functionality and then it will reboot. Please run this test for overnight or a couple of days and share the results log with us.

I have included my test result log: T20Log.log with the attachment for your reference.

If you want, you could extend the test application, connect the external reset board and toggle the connected GPIO in the application to simulate Power OFF/ON or Reset.

Please run this test case on the standard release image (v2.3) without running your application.

andreas · March 10, 2020, 6:08am

Because of lack of time I have to stop here and stay on BSP 1.4, but now with the newest Windows CE updates from Dec 2019. This works perfect.

The error seems to appear in combination of our additional drivers and the new BSP 2.3. With the BSP version 1.4 everything works ok.

Thanks for your support.