How do you eliminate flickering when GUI_Init() is called again in the firmware after being used in the bootloader?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • How do you eliminate flickering when GUI_Init() is called again in the firmware after being used in the bootloader?

      After displaying the boot screen in the bootloader and then jumping to the firmware,
      calling the GUI_Init() function causes the main screen to flicker before appearing.
      How can this issue be resolved?

    • Hello,

      depends on your LCD hardware and whether it supports LCD backlight "on/off" commands using some interface or GPIOs.

      Or maybe it has a brightness control using PWM when you can set the brightness to zero value.

      Why not make like this: turn backlight off before jumping to the target firmware and then turn it on again after calling GUI_Init() in the target maybe with a delay insertion in order to avoid fluctuations within the LCD peripherals to be visible. At least somehow you managed to avoid it in the bootloader.
      Regards,

      Anthony

      The post was edited 2 times, last by cilmagemlu ().

    • Hi,

      I think turning on/off the backlight is the best approach.

      You can react on the command LCD_X_ON / LCD_X_OFF in the display driver callback function LCD_X_DisplayDriver(). Similar to this:

      C Source Code

      1. int LCD_X_DisplayDriver(unsigned LayerIndex, unsigned Cmd, void * pData) {
      2. int r;
      4. switch (Cmd) {
      5. case LCD_X_ON: {
      6. LCD_BacklightOn();
      7. return 0;
      8. }
      9. case LCD_X_ON: {
      10. LCD_BacklightOff();
      11. return 0;
      12. }
      13. default:
      14. r = -1;
      15. }
      16. return r;
      17. }
      Display All

      GUI_Init() will send LCD_X_ON command after the controller has been initialized (LCD_X_INITCONTROLLER) and the screen has been cleared with black.

      You can use also the functions LCD_On() and LCD_Off() to send the on/off commands to the callback function.

      Regards,
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • The methods suggested seem to only temporarily display a black screen to avoid flickering before showing the firmware's screen, right?
      I'm not proficient in English, so I wasn't able to accurately describe what I want. What I'm looking for is as follows:
      1. Display a logo screen and progress bar on the LCD from the bootloader using emWin.
      2. Download the firmware to DRAM via SPI, and then jump to the downloaded firmware's address.
      3. To display a GUI in the firmware, re-invoke GUI_Init() to make emWin usable again.
      I want the transition from the bootloader's logo screen to the first main screen of the firmware to be smooth and fast, without any flickering or black screens, as if double buffering has been applied.
      However, this issue occurs when re-executing GUI_init(); in the firmware.
      I am developing using Nuvoton's N9H30 HMI board.
      Can you explain even a rough mechanism?

      The post was edited 1 time, last by shinec712 ().

    • I just solved this issue. The principle of LCD output is as follows:
      1. In the lcd.c driver provided by Nuvoton, a buffer is created to be used as VRAM and is then assigned to a global variable named "g_VAFrameBuf".
      2. The address of this buffer is registered with the N9H30 LCD controller's video stream frame buffer register.
      3. The LCD displays output by reading the values from this buffer.
      I'm not sure why, but I found out that calling GUI_Init() resets the buffer allocated to g_VAFrameBuf.
      If GUI_Init() is called without any buffer assigned to g_VAFrameBuf, it results in a runtime error.
      I am curious about how the GUI_Init() function clears this buffer. g_VAFrameBuf is declared as extern in LCDConfig.c, but is this related?

      Anyway, To ensure the continuity of the VRAM buffer from the bootloader into the firmware, the problem was resolved by switching the buffer in the LCD controller register only after the initialization and first screen rendering of the firmware's VRAM buffer had been fully completed.