Hello! I imported into standard make project FreeRTOS_V4.5.0_LM3Sxxxx_GCC_Eclipse.zip archive file (CodeSourcery G++ IDE) and successfully built it, flash it,… But when i start to debug it most of the time it stucks into FaultISR. If I just reset board without debugging – everything is working fine. Do you have any idea what’s going on? lino

I have never used the CodeSourcery IDE, what does it use as its debug interface?  The FreeRTOS.org demos are configured to use OpenOCD, is this what you are using? Can you step through the code to see at which point the exception occurs? Regards.

Did you follow the instructions from the FreeRTOS site? These do not use the code sorcery IDE, is it just standard Eclipse?

cs debug interface is integrated on lm3s6965 ev board exception occures in function pvPortMalloc (heap_2.c) on line: /* Insert the new block into the list of free blocks. */ prvInsertBlockIntoFreeList( ( pxNewBlockLink ) ); regards.

"cs debug interface is integrated on lm3s6965 ev board" -> there must also be a piece of software that sits between GDB and the ev board.  If this is transparent to you then I would guess it is not OpenOCD but instead built into the cs distribution. pvPortMalloc() is a strange place to get this issue. Its just straight C code and not doing any clever scheduling stuff. It might be that the CStartup initialization is not running correctly. Can you start the app running again with a break point at the start of pvPortMalloc() so you can step through the code the first time it is called. You should see that xHeapHasBeenInitialised is false, causing prvHeapInit() to be called.

but not always at the same line of code. 2nd time execute "halt" in vCreateBlockTimeTasks function. xQueueCreate returns NULL (no available memory?) and then stuck when executing xTaskCreate… 3rd time execute "halt" in main: first call to xTaskCreate: vPortYieldFromISR … vTaskSwitchContext (xMissedYield = pdTRUE;) xPortPendSVHandler -> FaultISR // The hard fault handler ???!

"there must also be a piece of software that sits between GDB and the ev board. If this is transparent to you then I would guess it is not OpenOCD but instead built into the cs distribution. " - that’s right. it’s not openocd.

It still sounds like the C startup code is not executing correctly when you run via the debugger. Did you check the state of the xHeapHasBeenInitialised variable as per my previous suggestion? What did you find?

xHeapHasBeenInitialised    = 1 prvHeapInit is never called. what to do?

Set a break point in ResetISR() within startup.c. This is where the variables should get initialized. Make sure startup.c is compiled WITH OPTIMIZATION even if the rest of the project is not. If this file is not optimized then the loops within ResetISR() will overwrite the loop counters.

project is built using original makefile – there shouldn’t be any problems with switches etc. i put breakpoint but never reached it. it goes straight to main.

Then I suspect that the cs compiler or more likely debug interface is behaving very differently to that which might be expected. You need to get onto cs about this, switch to a known working tool chain for the project, or find some cs examples or documentation that tell you how their debugger starts up.

I agree. This must be something in CS. I was debugging the same bin with gdb from command prompt. Thx for help! Long live FreeRTOS, OpenOCD, Eclipse and all other open source solutions! :-)