GUI_SetBkColor() does not work for GUI_BLACK and few other colors

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

  • GUI_SetBkColor() does not work for GUI_BLACK and few other colors

    I am using two functions GUI_SetBkColor() and GUI_SetColor() in WM_PAINT event to set background color and text/drawing color respectively.

    Out of the two above,
    GUI_SetColor() does what is should, but GUI_SetBkColor() causes a grayish flickering display if I select GUI_BLACK and many other colors.

    What can be the cause of this?

    Some information that might help is:
    • Color conversion used is GUICC_M565, so pixel width is 2 Bytes.
    • Display used is 320x240
    • LCD Clock is 6400000 Hz
    • In GUIConf.c, I have set GUI_NUMBYTES to (1024 * 1024) * 4
    • In GUIConf.c, I have set GUI_BLOCKSIZE to 0x80
    Please find attached LCDConf.c, GUIConf.c, GUI_X.c
    Files
    • GUI_X.txt

      (4.41 kB, downloaded 378 times, last: )
    • LCDConf.txt

      (20.67 kB, downloaded 446 times, last: )
    • GUIConf.txt

      (3.48 kB, downloaded 324 times, last: )
  • Hi,

    In LCD_X_Config() you tell emWin that the framebuffer is located at address 0x00000000.

    C Source Code

    1. LCD_SetVRAMAddrEx(0, (void*)VRAM_ADDR_VIRT);


    In LCD_X_DisplayDriver() you call this function again but with another address.

    C Source Code

    1. LCD_SetVRAMAddrEx(LayerIndex, (void*)VRAM_ADDR_PHYS);


    I recommend to set the address only in LCD_X_Config() this will help avoiding confusion.

    Since, the second call is the last one I guess emWin tries to write at the address of _aVRAM[0]. So, after calling GUI_SetBkColor(GUI_BLACK) and a GUI_Clear() I would expect the appropriate values at the address of _aVRAM[0] (with GUI_BLACK only 0x0000). Please check what gets written into the framebuffer.

    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.
  • Hi,

    Thanks for responding. I went through the LCDConf.c file and have set the address only in LCD_X_Config().


    After that I programmed the device and connected the debugger, set a breakpoint in WM_PAINT at before statement GUI_SetBkColor(). I can see the contents at address of _aVRAM[0] does not change after the execution of GUI_SetBkColor() and GUI_Clear();


    I have attached the two screenshots of the memory window.


    The problem persists.
    Images
    • Before.PNG

      28.85 kB, 410×591, viewed 322 times
    • After.PNG

      23.15 kB, 411×595, viewed 339 times
  • Hi,

    Are you able to write directly into the framebuffer (e.g. via the memory window)?

    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.
  • Hi Sven,

    I'll try writing directly into the framebuffer.
    I have looked into the code and I can see we are using MEMDEV, it is enabled.

    Also, I tried setting the gradient instead of a solid color, it still results in a grayish screen, the result is same for WINDOW_SetDefaultBkColor(). I guess it fails for larger data dump on LCD, because GUI_SetBkColor() works absolutely fine.

    What might cause this?
  • Hi Sven,

    Recently I've been facing a similar problem. As I confirmed usıng the debugger, the code hits GUI_Init, then GUI_SetBkColor and then GUI_Clear; after executıon of GUI_Clear, screen is updated with the programmed color and after a very short-time (100-200ms), it then switches to display in WHITE again.

    The framebuffer is located in external SDRAM and I verified that it is not updated. The framebuffer stays all 0xFF.

    That makes me search this problem on WEB, then I see this thread in this forum. Here you've asked the following question, which explains my case:

    Are you able to write directly into the framebuffer (e.g. via the memory window)?



    What would be the reason of this problem? Please help me to figure out.

    PS: I am using a custom board with LPC1788 using an external SDRAM (16MB,[font='&quot']MT48LC4M32B2P-7). I verified that without trying to use EMWIN, I managed to display a small picture using the same framebuffer (located in SDRAM) which makes me think that it is EMWIN related problem that can be solved by just a parameter update, well known for EMWIN experts.[/font]


    C Source Code

    1. void MainTask(void) {
    2. GUI_Init();
    3. GUI_SetBkColor(GUI_RED);
    4. GUI_Clear();
    5. while(1){GUI_Delay(500)}
    6. }