HardFault after migrating to Keil ARM MDK when first image control is loaded

Question

Hi,

after purchasing the Pro version of Embedded Wizard, we're attempting to migrate the UI generated from Embedded Wizard into our "native" environment/source tree (Keil MDK).  Our hardware platform is the STM32F7 discovery disco.

We currently have a Keil project that builds and links all Embedded Wizard RTE and STM32F7 HAL/platform package source code, with a Keil-based startup file that sets up heap and stack sizes to be the same as those used by the gcc environment.  I'm consistently getting a hard fault when the EwWiMainLoop executes, specifically during an attempt to create the rootObject with a call to EwNewObjectIndirect.

The hard fault always occurs the first time a control that uses an image is attempted to be initialized:

ControlsStartButton__Init >> _this->BitmapProperty = EwLoadResource( &ResNextFramesBitmap, ResourcesBitmap  >> ViewsImage_OnSetBitmap( &_this->Image, EwLoadResource( &ResNextFramesBitmap, ResourcesBitmap

The heap manager (tlsf.c) is what ultimately causes the fault.

I'm assuming I have a either the memory space setup incorrectly, or there is some other locating error, but I can't seem to find any glaringly obvious differences between my Keil projectand the gcc makefile.  Are controls with images handled any differently from other types of controls (where they store data, etc)?  Knowing what these differences are might help me to narrow down the actual cause for the hard fault.

Any suggestions/hints would be greatly appriciated

thanks!
Brian Amos

Answer 1

Hi Brian,

of course, it is difficult to give you good advices without having the environment on the table...

I think the hard fault is just the result - the reason happens earlier or the root cause is more system / initialization related. Nevertheless, some ideas or things you can test / verify:

Maybe the system initialization is different (e.g. SDRAM timing) - you can make a simple memory test, to ensure that the SDRAM can be read/written without any errors: place the following lines just before the call to tlsf_create_with_pool() in main.c

{
  unsigned char* ptr;
  unsigned char  data;
  unsigned long  count;

  EwPrint( "Check memory addr 0x%08X size 0x%08X\n", MEMORY_POOL_ADDR, MEMORY_POOL_SIZE );
  EwPrint( "Write test pattern to SDRAM...               " );
  ptr = (unsigned char*)( MEMORY_POOL_ADDR );
  data = 0x00;
  count = MEMORY_POOL_SIZE;
  while ( count-- )
  {
    *ptr++ = data++;
    if ( data >= 253 )
      data = 0;
  }
  EwPrint( "[OK]\n" );

  EwPrint( "Read test pattern from SDRAM...              " );
  ptr = (unsigned char*)( MEMORY_POOL_ADDR );
  data = 0x00;
  count = MEMORY_POOL_SIZE;
  while ( count-- )
  {
    if ( *ptr++ != data++ )
      EwPrint( "Error at address 0x%08X\n", ptr-1 );
    if ( data >= 253 )
      data = 0;
  }
  EwPrint( "[OK]\n" );
}

If the memory test is successful, you can try to allocate and free memory chunks. After the memory manager is intialized, you can call EwAlloc() to allocate memory areas and EwFree() to free them. This ensures, that the memory manager operates properly.

Does this work?

Comments

Thanks for the memory test code, Manfred.  It worked perfectly, so I was able to quickly verify that RAM was working properly.  This was very helpful.

It turns out the issue stemmed from the GCC global #defines in the makefile.  I had put these into a sinlge header file in Keil uVision, but failed to include it from all the necessary files.  Keil only includes #defines if the source file references the exact header they are defined in (there's also an option to define them globally, but it's clunky, imho).

The embedded wizard code was failing a EW_SURFACE_ROTATION check in EwBmpOpen() and throwing various errors that weren't visible, since I dind't have the UART attached to a serial port.

All of the UI migration issues have been resolved and I'm now running the UI on our target h/w, with code generated from Keil.