Hard_Fault during Update(viewport, rootObject)

256 views
asked Mar 30, 2017 in System Integration by David_Micallef
Hi,

I am currently running the evaluation version with STM32F746 Discovery board.  I have managed to build an application, make and install it using the commandline environment you provided and works perfect. (No FreeRTOS and No QSPI)

Next I proceeded to integrating the build environment in Crossworks ARM (gcc).  I added all files, the libraries, compiler options, etc.  Basically all the files are from EW toolchain and the ST drivers as per your supplied makefile.  The only things I am not using from the EW build enviornment is the Linker script, memory map and the STM32_Startup.s  (these are the provided ones by Crossworks).  I modified the stack and heap sizes according.  

The application compiles perfectly and I can download it and start debuging it, the program goes into the EmWiMainLoop and then when it reaches Update(viewport,rootObject), it crashes and goes into HardFault_Handler

From the debugger it seems the trace of ending in the HardFault_Handler is

HardFault_Handler<EeFindGlyph()<EwScreenWarpAlpha8RowFilterGradientBlend()

My opinion is this is something to do with the memory map, would you be able to point me in the right direction as to what is causing this issue.  I really want to be sure all this works before buying the licence.

2 Answers

0 votes
answered Mar 30, 2017 by mli
Hi David,

did you already checked the console output?

Another posibility to find out the reason could be to compare the map files of both builds.

Regards,
Martin
0 votes
answered Mar 30, 2017 by Manfred Schweyer

Hi David,

it's difficult to find the root cause without having the entire system on the table...

First of all, the provided Build Envrionment is prepared and tested with the GCC compiler in combination with the provided makefiles, startup code,... The Evaluatioin Edition of the STM32 Platform Package contains only libraries, that are compiled with GCC and the corresponding runtime libraries. Although it might be possible to link these libraries with other toolchains - the behaviour might be unpredictable...

The main idea of the Evaluation Edition is the familiarization with Embedded Wizard and its workflow. When you are using the Profdessional Edtion of Embedded Wizard Studio, you will get the source code of the Runtime Environment and the Graphics Engine, so it will be easy to compile and link everything with the toolchain of your choice. As long as you are working with the Evaluation Edition, we recommend to use the provided setting as it is.

See also 'using stm32 build environment with third party toolchain'.

Best regards,

Manfred.

commented Mar 30, 2017 by David_Micallef
Hi Martin, Manfred,

Thanks for your replies.

@Martin

Console seems fine, it goes through the first initial messages and then shows: "System halted! [MemManage_Handler]\n"  But at that point it would have set up the viewport and all is working.

Memory map seems ok, I even ensured it has the 16byte alignment on the stack but I have to go deeper to understand everything.  What would be the most important parts to look for?

just a minor question, i am linking to libewgfx-eval.a  but I noticed there others in the folder -mu, -r90..... Is libewgfx-eval.a the correct one?

@Manfred, this is a gcc compiler (crossworks use gcc).  Still I understand that without access to the whole system it would be difficult to debug.  

Thanks
commented Mar 30, 2017 by Manfred Schweyer

Hi David,

yes, the libewgfx-eval.a and the libewrte-eval.a are the right choice. (-mu means 'memory usage' that have to be used when compiling with the flag EW_PRINT_MEMORY_USAGE and the -r90 / -r180 / -r270 are used when the project is created with a different ScreenOrientation).

Nevertheless, GCC compiler is one thing, the different compiler flags, the used libraries and the used startup-code is another issue that might have an impact to the resulting binary.

Best regards,

Manfred. 

commented Mar 30, 2017 by David_Micallef
somehow I managed to fix it.

I made crossworks use the external compiler and linker and then provided it with the startup and .ld file used in the template provided by EW.

Thanks for your help
commented Mar 30, 2017 by Manfred Schweyer
Yes this makes sense - now everything is done from one environment.

Thank you for sharing that information.

Embedded Wizard Website | Privacy Policy | Imprint

...