Splashcreen not shown on T20

Technical Support
, , ,
1

Hello

We compile our OS ourselves with your version 2.2. Since I updated our hardware with the BSP version 2.2 I’m no longer able to enable the splash screen. Even everything is set the same way in the configblock it is no longer shown.

Interestingly the ss.bsTeg parameter shows in the bootloader the value 0x8480C030 and when I read it with the ConfigBlockEditor it has the value I actually set - 0xF1612030. But I don’t think that this has something to do with each other.

Bootloader output of the splashcreen settings:

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:   255             (Display On/Off Gpio)
ss.bl_gpio:     255             (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:         0x0             (Reserved Flags)
ss.forcePLLD:   0x1             (Force use of dedicated Display PLL)
ss.res2:        0x1F            (Reserved Flags)
ss.bsTeg:       0x8480C030      (LCD Buffer Strength Tegra)

Thanks for any help.

2

Dear @andreas

I don’t have a clear answer, I hope the following hints help to track down the problem.

From which BSP version are you updating to V2.2? This might help us to understand the differences.

1. Make sure the display is powered

The backlight and disp gpios are configured to “not used”. Please verify that this is not relevant for your hardware. Verify that your backlight (if any) is on. You typically see the light even on a black picture, if you look at the edge of the display.

2. Buffer strength

I assume that the different bsTeg readouts are caused by an older, incompatible GpioConfig tool.
To exclude any issue, please set ss.bsTeg = 0xFFFFFFFF (maximum drive strength) for a test.

3. Missing Picture

We should find out whether the display does not show anything, or whether the splashscreen image is somehow invalid:

Configure ss.dbginfo=1 and reboot the system. If you see the messages on a black background, then it is an issue with the splashscreen image. If there is no text, there is an issue with the display timings or similar settings.

4. How Were the Settings Applied

The config block binary format has slightly changed in the past. It might lead to wrong results, if you restore a binary backup of the config block settings on the new V2.2 BSP.
Also the Configblock Editor can be inconsistent to the actual config block.
Try to do clear ss over the serial port and then enter all your settings over serial, too.

5. Clock Frequency

The deviation of the actual pixel clock frequency compared to the one configured in ss.pclk was improved. There’s a small chance that your display worked with a frequency which was not exactly 33.2MHz, but doesn’t properly work at 33.2MHz.

6. Standard Eboot

Did you only build your own WinCe image, or also your old bootloader? In the latter case, what happens if you use our default bootloader with your configblock settings?

I hope theses tests will give us more information about the source of the problem.

Regards, Andy

3

Thanks for your answer.

I did again some tests to find the problem. We always use your default bootloader.

It seems to be dependent of the bootloader version. Before we were using the version 2.1 beta1 of the bootloader and when I install this version again along the BSP version 2.2 it works fine. With the newest version 2.2 of the bootloader in some constelations of the Colibri Board and our mainboard the splashscreen only appears about 200ms before the OS takes over (instead of along the bootloader start) or in other constelations at least the backlight doesn’t switch on - undependent of the bl_polarity.

What we also observed since we updated to the version 2.2 is that sometimes after startup the display has a color shift in the direction to blue or it looks like the color resolution is not the set 16 bpp. This remains until a restart of the instrument.

That the pixel clock frequency might be the problem doesn’t look like to be the problem. Otherwise nothing could be seen on the display at all also when our application is running then. It uses the same parameters.

For me the question is: What makes the difference of installing Bootloader version 2.1 beta1 or version 2.2?

4

Dear @andreas
Let’s get back to my questions, to keep it structured:

  1. Power: I read in your comment that the backlight is somehow controllable by software. Hiowever, your configblock indicates that the bootloader should not do any configuration for the backlight ( ss.bl_gpio=255, ss.disp_gpio=255). If I understood this correctly, it explains the random behavior of the backlight, which could also change with the bootloader version.
    We should focus on this issue first - you need a stable backlight and display power to move on.
    Can you please provide me the details how your backlight and display power is connected to the Colibri module?
  2. Buffer strength: This will be the next test after 1. is solved.
  3. Missing Picture: If you always see the splashscreeen, even if it’s late, then this is not the problem (I’m not sure from your answer whether this is the case in all constellations)
  4. Configuration Process: I can’t say you more from the information in your comments
  5. Clock Frequency. WinCe timings are independent from the bootloader timings. So this could still be the problem, but as mentioned before, probably it is not.
  6. Standard Eboot: Done. As you are using our standard bootloader, we can exclude this.

Conclusion:
Please focus on getting a stable display and backlight power. I suggest to postpone all other tests until this part is solved.

Regards, Andy

5

I checked again the schematic and the backlight is set by the GPIO pin C6 on the T20 which also shares the function of the DCD of the UART_A interface. I could remember now that I had the same problem with the VF50 and there I had to make sure that the debug serial output was disabled dbg.serial 0. But this seems to not help on the T20.

How can I change the function of this pin in the bootloader? Is there a way to configure it as an output with value 1? Would I have to extend the configuration string of gpio.bootconf?

The display enable signal is wired to GPIO pin J1 (L_BIAS).

Might it be that there is a difference to the bootloader version 2.1 beta1 in the version 2.2?

Thanks.

6

Dear @andreas

For my further instructions, let’s first create a small translation table:

GPIO  GPIO(numeric) SODIMM pin Default function
----- ------------- ---------- ----------------
C6      22          31         UART_A_DCD
J1      73          44         LCD_BIAS

There’s 3 somewhat independent topics I need to explain:

1. Display-Enable

The display enable signal (GPIO J1) is a dynamic signal which toggles during each shown frame. You can compare it to a horizontal-sync signal.
The display driver handles this, so you don’t need to care about it.

The display-power signal I was referring to is something different: Many customers insert a switch to turn off the power supply of the display electronics to save power when the display is not needed. If there is a constant (3.3V?) power supply routed to your display, you probably don’t have such a switch and don’t need to care about controlling it.

2. Set GPIO C6 to High

With the explanation above, were only left with configuring GPIO C6 in the bootloader. It should be sufficient to execute the following commands in the bootloader menu, in order to configure the splashscreen block correctly:

x
set ss.bl_gpio 22
set ss.bl_pol 1
save ss

I never tested it with a pin that is used by the UART_A, so I’m not 100% sure that it works.

3. Prevent System Software From Changing GPIO C6

There’s two blocks of software which potentially touch this pin

  1. The bootloader while initializing the UART_A
  2. The Windows CE driver for UART_A

The bootloader is not an issue. It will anyway initialize only the Rx and Tx signals of UART_A.

For the WinCe driver it is a bit more complex:

  • As long as you have the debug messages enabled ( dbg.serial=1), Windows CE will not load the UART_A driver, therefore the pin configuration is not touched.

  • If you disable the debug messages ( dbg.serial=0), WinCe loads the driver by default. So there are two ways to prevent changing the pin configuration:

    1. Disable the UART_A driver completely
      [HKLM\Drivers\Builtin\Serial1]
      "Dll"="_libnvuart.dll"
    2. Configure the UART_A driver to use only Rx and Tx
      [HKLM\Drivers\Builtin\Serial1]
      "NumberOfLines"=dword:2

Regards, Andy