Bad memory access in GUI_Init()

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

    • Bad memory access in GUI_Init()


      Recently, I encountered an annoying issue causing freezing.
      It seems like dereferencing a null pointer.
      Please refer to the image below:

      It appears to happen in a call to LCD_INIT->GUI_SelectLayer->GUI_SelectLCD->LCD_UpdateColorIndices->LCD_SetColorIndex.
      Within that function r1 is loaded from a location with an offset of 0x3C, so probably a structure member.
      The content is loaded in r1, but is zero. The next instruction (see yellow arrow) stores r0 back to location zero and thus overwriting the initial stackpointer.

      I checked the soruce code:

      C Source Code: LCD.c

      1. void LCD_SetColorIndex(unsigned PixelIndex) {
      2. if (GUI_pContext->DrawMode & LCD_DRAWMODE_REV) {
      3. LCD__SetBkColorIndex(PixelIndex);
      4. } else {
      5. LCD__SetColorIndex(PixelIndex);
      6. }
      7. }

      C Source Code: GUI_Private.h

      1. #define LCD__SetBkColorIndex(Index) (*GUI_pContext->LCD_pBkColorIndex = Index)
      2. #define LCD__SetColorIndex(Index) (*GUI_pContext->LCD_pColorIndex = Index)
      3. #define LCD__GetBkColorIndex() (*GUI_pContext->LCD_pBkColorIndex)
      4. #define LCD__GetColorIndex() (*GUI_pContext->LCD_pColorIndex)
      From the image, you can get that: the value of GUI_pContext->LCD_pColorIndex is null!
      So, any solutions? Please save me!

      My project using:
      1) i.MX RT1050
      2) KEIL RTX OS2
      3) emWin v5.48j

      To catch this, I set ITCM read only to MPU.


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

    • Hi,

      Hard to say why pColorIndex is 0. In emWin are only two places where this pointer gets set. It gets set while GUI_Init(), initializing the context and when calling GUITASK_CopyContext(). GUITASK_CopyContext() has to be called by the user, so this is really strange.

      Do you have a chance to check at which point pColorIndex gets 0?
      On initialization it gets the address of GUI_pContext->uLCD.aColorIndex32[1], does it also has a strange address?

    • Hi Sven,

      Today I step into the vary functions.

      First, the values in the struct pointed by GUI_pContext seems okay after first initial:

      But, after calling GUI_LOCK() in the function GUI_SelectLayer() all cleared to 0:

      by this:

      Source Code: GUI_Task.c

      1. GUI_pContext = &_pSave[TaskNo].Context;
      It seems a context switching occurred.
      Then this pointer GUI_pContext->LCD_pColorIndex (its value is 0) is dereferenced.

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

    • Hi,

      do you use emWin from multiple tasks?

      If not you could build emWin with the GUI_OS set to 0. Setting the define to 0 will cause GUI_LOCK() to be defined as nothing.

      If you do, did you implemented the functions below properly?

      void GUI_X_Unlock(void);
      void GUI_X_Lock(void);
      U32 GUI_X_GetTaskId(void);

      Attached are some examples for different operating systems.


        (5.23 kB, downloaded 133 times, last: )
    • Hi Sven,

      I check the project over and over again and still the same story.
      For I step into this issue using the source codes, so it should not be the library.

      If I set ITCM read write to MPU, then the code runs well.
      (Yes, this bad memory access occurred, too.)

      For the address of ITCM start from 0x00000000, and we decide to put crucial code to it.
      So this issue makes the code crashing from the very beginning.

      Attached's the config file & OS specific file.
      I've removed the file header for the license info.

      I also check the two tasks: system tick task, background task, and they're running well.
      Before the function GUI_SelectLayer() being called, the two tasks run several times.

      So what should be the problem? Any ideas?


      The post was edited 6 times, last by kenmux ().

    • Hi,

      unfortunately, I'm no familiar with the MPU of the iMXRT1052.

      I just know that there where some issues with the MPU of the STM32F7 in the future. If it wasn't configured properly strange errors could occur (like pointers having strange addresses).

      I'm sorry, but maybe NXP can help you here.