FreeRTOS: HardFault in VListInsertEnd() - Stack Crash ?

paulromero wrote on Wednesday, February 06, 2019:

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(StackType_t* pxTopStack=0xaaaaaaa, TaskFunction_t* 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.

rtel wrote on Thursday, February 07, 2019:

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.

paulromero wrote on Thursday, February 07, 2019:

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
NVIC_EnableIRQ() and NVIC_DisableIRQ() which I think is correct.
I think the FAQHelp document is referring to enabling or disabling
all interrupts.

Best Regards,

Paul R.

paulromero wrote on Thursday, February 07, 2019:

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.

rtel wrote on Thursday, February 07, 2019:

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.

paulromero wrote on Thursday, February 07, 2019:

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