emWin gets stuck in GUI_Init

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Valametti on Wed May 27 05:02:07 MST 2015
I have a project for LPC1768 mbed platform that draws simple graphics into Sharp memory LCD using prebuild emWin library.

I exported the code from mbed online compiler and compiled it using using LPCXpresso. It works great, although first I had to play with library settings in order to get LPCXpresso to find the correct emWin library.

My company is using plain make and arm-none-eabi-g++. Therefore I exported the project also to GCC (Arm embedded). After getting the libraries right, the code compiles and runs, but gets stuck in GUI_Init().

Any idea what's wrong? I don't know if the code crashes or is in some infinite loop. The mbed lights don't blink.

Below, there are snippets of the emWin config files and main.cpp I have. They include some logging:

GUI_X.c:

#include "GUI.h"
#include "trace.h"

volatile GUI_TIMER_TIME OS_TimeMS;

void GUI_X_InitOS(void)    { /*OS_CreateRSema(&RSema);*/    }
void GUI_X_Unlock(void)    { /*OS_Unuse(&RSema);*/ }
void GUI_X_Lock(void)      { /*OS_Use(&RSema);*/  }
U32  GUI_X_GetTaskId(void) { return 0; /*(U32)OS_GetTaskID();*/ }


GUI_TIMER_TIME GUI_X_GetTime(void) {
    DEBUG("GUI_X_GetTime\r\n");
  return OS_TimeMS;
}

void GUI_X_Delay(int ms) {
    DEBUG("GUI_X_Delay %d\r\n", ms);
  int tEnd = OS_TimeMS + ms;
  while ((tEnd - OS_TimeMS) > 0);
}

void GUI_X_Init(void) { DEBUG("GUI_X_Init\r\n"); }

void GUI_X_ExecIdle(void) { DEBUG("GUI_X_ExecIdle\r\n");}

void GUI_X_Log     (const char *s) { DEBUG("Log: %s\r\n", s); }
void GUI_X_Warn    (const char *s) { DEBUG("Warn: %s\r\n", s); }
void GUI_X_ErrorOut(const char *s) { DEBUG("ErrorOut: %s\r\n", s); }

GUIConf.c:

#include <string.h>
#include <stdint.h>
#include "GUI.h"
#include "trace.h"

#define GUI_NUMBYTES  1024 * 4

#define GUI_BLOCKSIZE 0x128

void GUI_X_Config(void) {
    DEBUG("GUI_X_Config \r\n");
    static uint8_t aMemory[GUI_NUMBYTES];

    GUI_ALLOC_AssignMemory(aMemory, GUI_NUMBYTES);
    GUI_ALLOC_SetAvBlockSize(GUI_BLOCKSIZE);

    GUI_SetDefaultFont(GUI_FONT_8X16);
}

LCDConf.c:

#include "GUI.h"
#include "GUIDRV_Lin.h"
#include "trace.h"

#define XSIZE_PHYS 416
#define YSIZE_PHYS 240

#define COLOR_CONVERSION GUICC_1

#define DISPLAY_DRIVER GUIDRV_LIN_1

void LCD_X_Config(void) {

    DEBUG("LCD_X_Config");

    GUI_DEVICE_CreateAndLink(DISPLAY_DRIVER, COLOR_CONVERSION, 0, 0);

    LCD_SetSizeEx (0, XSIZE_PHYS, YSIZE_PHYS);
    LCD_SetVSizeEx(0, XSIZE_PHYS, YSIZE_PHYS);

}

int LCD_X_DisplayDriver(unsigned LayerIndex, unsigned Cmd, void * pData) {
    DEBUG("LCD_X_DisplayDriver layer: %x, cmd: %x, data %p\r\n", LayerIndex, Cmd, pData);
    switch (Cmd)
    {
        case LCD_X_INITCONTROLLER: {
          return 0;
        }
        default: {
          return -1;
        }
    }
}

main.cpp:

int main(void) {
...
    DEBUG("START\r\n");
...
    DEBUG("Entering GUI_Init\r\n");
    led4 = GUI_Init();
    DEBUG("Exited GUI_Init\r\n");

The output logs are as following:
LPCXpresso, Works OK:

START
Entering GUI_Init
Log: 
     GUI_Init()
GUI_X_Config 
LCD_X_ConfigLCD_X_DisplayDriver layer: 0, cmd: 7, data 0x10007b28
GUI_X_Init
Log: 
     LCD_Init...
LCD_X_DisplayDriver layer: 0, cmd: 1, data 0x0
LCD_X_DisplayDriver layer: 0, cmd: 4, data 0x10007b08
LCD_X_DisplayDriver layer: 0, cmd: 4, data 0x10007b08
LCD_X_DisplayDriver layer: 0, cmd: 5, data 0x0
LCD_X_DisplayDriver layer: 0, cmd: 3, data 0x10007b38
Log: 
     GUI_ALLOC_Alloc... requesting %d, %d avail 0x0000002C 0x00000838
Log: 
     GUI_ALLOC_AllocNoInit... requesting %d, %d avail 0x0000002C 0x00000844
Log: 
     GUI_ALLOC_AllocNoInit : Handle 0x00000002
Exited GUI_Init
LCD_X_DisplayDriver layer: 0, cmd: 2, data 0x10007b64

GCC Arm Embedded, gets stuck in GUI_Init()

START
Entering GUI_Init
Log: 
     GUI_Init()
GUI_X_Config 
LCD_X_ConfigLCD_X_DisplayDriver layer: 0, cmd: 7, data 0x10007b30
GUI_X_Init
Log: 
     LCD_Init...
LCD_X_DisplayDriver layer: 0, cmd: 1, data 0
LCD_X_DisplayDriver layer: 0, cmd: 4, data 0x10007b10
LCD_X_DisplayDriver layer: 0, cmd: 4, data 0x10007b10

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Valametti on Tue Jun 02 05:28:59 MST 2015
I ported the configuration to LPCXpresso and the same problem happens there also. I tried to move the display frame buffer and emWin's memory block to AHB RAM block to free some memory. Seems that emWin (or someone else) doesn't like that. I get hard fault again. Can you tell there are some restrictions of the data location for the prebuilt emWin library?

The only change I made was that I placed __BSS(RAM2) statements in front of two variables.


__BSS(RAM2) FrameBuffer buffer; //Global variable

... and

void GUI_X_Config(void) {
__BSS(RAM2) static uint8_t aMemory[GUI_NUMBYTES];
...

the map file tells the variables should be about in the correct place:

...
.bss_RAM2       0x2007c000     0x48c0
 *(.bss.$RAM2*)
 .bss.$RAM2     0x2007c000     0x30c0 ./src/main.o
                0x2007c000                buffer
 .bss.$RAM2     0x2007f0c0     0x1800 ./emWin_Config/GUIConf.o
...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Mon Jun 01 07:21:14 MST 2015
So hard faults are typically caused by stack overflow or being out of heap. Although focussed on debugging with LPCXpresso, you may find this useful background:

http://www.lpcware.com/content/faq/lpcxpresso/debugging-hard-fault

And again, although I can't give you generic GCC advice, the following LPCXpresso FAQs may give you some clues on things to look at in your setup:

http://www.lpcware.com/content/faq/lpcxpresso/heap-checking-redlib
http://www.lpcware.com/content/faq/lpcxpresso/startup-code-interrupt-handlers
http://www.lpcware.com/content/faq/lpcxpresso/own-linker-scripts

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Valametti on Mon Jun 01 05:31:29 MST 2015
Well, It's not any infinite loop, but hard fault. I took some debug prints and got the following results:

extern "C" void HardFault_Handler() {
   DEBUGLN("In Hard Fault Handler\n");
   DEBUGLN("SCB->HFSR = 0x%08lx\n", SCB->HFSR);
   DEBUGLN("SCB->DFSR = 0x%08lx\n", SCB->DFSR);
   DEBUGLN("SCB->CFSR = 0x%08lx\n", SCB->CFSR);
   DEBUGLN("SCB->MMFAR = 0x%08lx\n", SCB->MMFAR);
   DEBUGLN("SCB->BFAR = 0x%08lx\n", SCB->BFAR);
   DEBUGLN("SCB->AFSR = 0x%08lx\n", SCB->AFSR);

   while(1);
}

Outputs:

In Hard Fault Handler

SCB->HFSR = 0x40000000

SCB->DFSR = 0x00000008

SCB->CFSR = 0x00000400

SCB->MMFAR = 0xe000ed34

SCB->BFAR = 0xe000ed38

SCB->AFSR = 0x00000000

Is this related to emWin, or something else? "SCB->CFSR = 0x00000400" Does that indicate that the fault happened somewhere before? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Cihcfefj.html

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Valametti on Thu May 28 23:18:03 MST 2015
Thanks for tips. The linker scripts and the map files are different, indeed. However I don't know them well enough to spot the problems. Is there any way to see, if I'm running out of stack or RAM?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed May 27 05:26:38 MST 2015
So the obvious difference between an LPCXpresso IDE project and a vanilla GCC build that you probably want to compare are going to be:

1) Linker scripts
2) Startup code
3) Library usage (e.g Newlib vs Newlib Nano - I assume as you are exporting from mbed this is all C++, so no Redlib library usage)
4) Heap and stack location and potentially size.

Looking at the two linker map files would be where I would start.

Regards,
LPCXpresso Support