Hardfault when calling GUI_Clear, thread related ?

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

    • Hardfault when calling GUI_Clear, thread related ?



      Based on the discussion in Direct framebuffer access, I started using memdevs.
      But now I run into an exception during when calling GUI_Clear() when the memdev is active (though it might not be memdev related, so i created new topic).

      I am using stemwin in a freertos multitasking environment.
      The memory I give to emwin (and in which the memory buffer is located) is located in external SRAM.

      IAR linker file:
      place in ExtSRam_region { block HEAP, section EXT_MEMORY_IF_AVAILABLE };


      Source Code

      1. #define GUI_NUMBYTES (1024) * 64
      2. static U32 extMem[GUI_NUMBYTES / 4] @ "EXT_MEMORY_IF_AVAILABLE";
      3. void GUI_X_Config(void)
      4. {
      5. GUI_ALLOC_AssignMemory(extMem, GUI_NUMBYTES);
      6. }
      The calls I do are

      From a Freertos task A:

      Source Code

      2. if ( 0 == m_hMemDev )
      3. {
      4. LOGGER_LOG_ERROR( LOG_CLASS, "%s: Could not create memdev", __FUNCTION__ );
      5. l_nResult = e_RETURNVALUE_Failure;
      6. goto lbl_err;
      7. }
      8. GUI_MEMDEV_Select(m_hMemDev);
      9. // debug test, this works fine, just adding stuff from the other thread
      10. GUI_Clear();
      11. {
      12. volatile void * mypointer;
      13. mypointer = GUI_MEMDEV_GetDataPtr( m_hMemDev );
      14. GUI_Clear();
      15. }
      Display All

      Then some other code runs, and finally from a different freertos task I do again

      and i get a hardfault.

      Debugger further the point where it goes wrong gives me a call stack:
      GUI_Clear -> WL__InitIVRSearch -> GUI_ALLOC_UnlockH

      GUI_ALLOC_UnlockH contains on the 7th line in assembler the instruction:
      LDRB.W R3, [R0, R5, LSL #3]

      This is passed 3 times correctly with R3 having value 0x6804003C
      Then a 4th time correctly with R3 being 0x68040074
      And then the 5th time R3 is 0x00000009 which of course causes the hard fault.

      ( 0x6804xxxx is all inside the extmem buffer passed on to emwin)

      Any suggestions what might be going wrong ?
      I dumped the complete contents of the extMem buffer passed to emwin to see if maybe something got corrupted there, and the only difference i have is that at the end of region some 0x0000 is replaced by 0x1841, which happens during the execution of GUI_MEMDEV_GetDataPtr.
      (intel hex format, offset 0 is start of the extMem buffer)
      I even tried clearing that to 0000 again but this did not solve the problem, so i am guessing it is totally unrelated and the problem is not some memory corruption.

      It seem/might be related to the fact that i call the function from a different thread (?). Is that no allowed for some reason ?

      Sideremark: the problem seems similar to emWin with external SRAM error, though maybe that one had a different cause(no thread relation ?)

    • New

      Hi Bram,

      Is GUI_OS defined to 1 in the GUIConf.h?

      If this is defined to 0 or not defined (which is the same as defining it to 0) it is not allowed to call emWin from multiple tasks.

      If it is defined to 1 avoid calling GUI_Exec()/GUI_Delay() from multiple tasks. Only one task should call these functions.

      Not sure what exactly you are doing with memory device pointer, but might it be possible that you overwrite memory at some point?

    • New

      Hi Sven,

      GUI_OS is set to 1.
      GUI_MAXTASK is not defined. Manual says the default is 4. I have more tasks in my system but I am only calling it from 2 tasks now.
      * GUI_X_GetTime()
      * GUI_X_Delay(int)

      * GUI_X_InitOS()
      * GUI_X_GetTaskId()
      * GUI_X_Lock()
      * GUI_X_Unlock()

      * GUI_X_GetTaskId
      * GUI_X_WaitEvent
      * GUI_X_SignalEvent
      functions have an implementation (provided by ST, if you think these may be involved i can go start checking them)

      I am actually not calling GUI_Exec/GUI_Delay at all at the moment, is that be a problem ?
      The only function I currently plan to use at the moment is to display text, some primitive drawing functions possibly later.
      (GUI_Exec is not even in the map file , the compiler pruned it out)

      I was not doing anything with the pointer yet (it was a local variable), but to check for possible corruptions (who knows, maybe some other task was writing incorrectly in emwin memory) I did the memory compare of the region passed to emwin before and I only had one difference (see previous post) resulting from the GUI_MEMDEV_GetDataPtr operation.

      Nevertheless, i now simplified my test scenario even more, I just do a GUI_MEMDEV_Select(m_hMemDev) + GUI_Clear() from one thread, and then a GUI_Clear from another thread.
      If I dumpe the extMem region before the calls, they are identical.
      But i still have a problem but at a slightly different location this time.
      The call stack is now :
      GUI_Clear -> LCD_FillRect -> _FillRect -> _memset16
      And it crashes because R0 (the first argument ) contains some bogus address (in de correct case it contains an address of the memdevice region).

      I see that the incorrect address is derived from calling GUI_ALLOC_LockH earlier, which I think should return addresses inside the extMem region, but in the erronous case it returns 0x00000009 (again the value 9, the same as in the original error).

      Does emwin store state information at some other place than the memory region passed to it ?
      If not , then the only difference between the 2 calls is the fact that the second call happens from a different thread (?)
      What is the functionality of the GUI_ALLOC_LockH functions