Dear Staff: I am using FreeRTOS Kernel Version V8.0.1 with version 3.2 of the Roweley Crossworks for ARM toolchain which uses the GCC compiler. The target environment for the code is the Embedded Artist’s LPC4088 dev. board with an NXP LPC4088 Cortex M4 MCU. The Crossworks toolchain is running under Debian Linux. (NOTE: configASSERT() is defined in the normal way in FreeRTOSConfig.h()) Also, the following problem does not occur with version XXX of Crossworks. The problem is that after using xTimerStart() to start a timer the following completely reproducable HardFault crash occurs during a call to vListInsertEnd().

149 DEFAULT_ISR_HANDLER HardFault_Handler

It occurs in VListInsertEnd() at the line labled CRASH below.

void VListInsertEnd( List_t * const pxList, ListItem_t * const pxNewListItem )
{
ListItem_t * const pxIndex = pxList->pxIndex;

    /* Insert a new list item into pxList, but rather than sort the list,
    makes the new list item the last item to be removed by a call to
    listGET_OWNER_OF_NEXT_ENTRY(). */
    pxNewListItem->pxNext = pxIndex;
    pxNewListItem->pxPrevious = pxIndex->pxPrevious;    // CRASH

The attached file, stack.png, shows the stack trace. These are some other relevant clues.

• pxPortInitialize() stack appears to have executed many times at the time of the crash and the last instance is as follows: 0x0000937E void pxPortIntialiseStack(StackTypet* pxTopStack=0xaaaaaaa, TaskFunctiont* pxCode=0xaaaaaaaa port.c : 239
• In VlistInsertEnd(), all fields of pxIndex have the value 0xaaaaaaaa.

I think, but don’t know, the problem is something technical rather than a normal stack crash. Best Regards, Paul R.

I am using FreeRTOS Kernel Version V8.0.1

Gosh, why are you using such an old version?

with version 3.2 of the Roweley Crossworks for ARM toolchain which uses the GCC compiler. The target environment for the code is the Embedded Artist’s LPC4088 dev. board with an NXP LPC4088 Cortex M4 MCU. The Crossworks toolchain is running under Debian Linux. (NOTE: configASSERT() is defined in the normal way in FreeRTOSConfig.h()) Also, the following problem does not occur with version XXX of Crossworks.

Ok, so I think what you have just said is the problem exists with one version of GCC, but not another, but you haven’t said whether it is the older or the newer version of GCC that you have success with. Looks like stack corruption, but it is difficult to say if the problem is the kernel code, or the compiler, as you indicate it works fine with a different version of the compiler. My first suggestion would be to read through all the points in this page from the FAQ https://www.freertos.org/FAQHelp.html then, if that does not help, to update to the very latest version of FreeRTOS. It is not that I’m aware of any bugs in older versions, but the newer the version the more configASSERT() points there are to catch misconfigurations that could result in critical sections not functioning correctly. The latest version will catch nearly all, if not all, errors in configuration the kernel to match the NVIC implementation in your FreeRTOS configuration.

Hi Richard: I looked at the FAQHelp document and think the only thing I am doing that does not conform is how I disable and enable particular interrupts. When I need to enable or disable a particular interrupt I use NVICEnableIRQ() and NVICDisableIRQ() which I think is correct. I think the FAQHelp document is referring to enabling or disabling all interrupts. Best Regards, Paul R.

More technical information: The same code works on Crossworks Version 4.2 running on a Ubuntu Linux system. The GCC version on that system is 4.9.2 and the Ubuntu version is 4.9.2. The GCC version on the Debian system is 4.7.2 and the Debian version is 4.7.2.

I know its an obvious question – but I have to ask – if it works with the later GCC version then why not use that? I know there were some changes in GCC that required some code updates in the FreeRTOS port layer.

Additional Detail: I have stack overflow checking enabled and the hook function– vApplicationStackOverflowHook() is not being called.