FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2008 Threads] Can usTaskCheckFreeStackSpace() be right?Posted by JohnnyBosc on October 21, 2008 I'm a tad confused abt. the usTaskCheckFreeStackSpace() function in task.c. Allow me to quote it in full (sry 'bout that) from the provided source code:
unsigned portSHORT usTaskCheckFreeStackSpace( const unsigned portCHAR * pucStackByte ) { register unsigned portSHORT usCount = 0;
while( *pucStackByte == tskSTACK_FILL_BYTE ) { pucStackByte -= portSTACK_GROWTH; usCount++; }
usCount /= sizeof( portSTACK_TYPE );
return usCount; }
Now, on a PIC32 MCU portSTACK_GROWTH is = -4, i.e. every iteration in the while() loop will increase the tested address by 4 -- looks very much like we're counting 32-bit integers, doesn't it?
However, on exiting the while() loop the count of 32-bit integers in usCount is divided by sizeof(portSTACK_TYPE)!
In the PIC32 port, sizeof(portSTACK_TYPE) is = 4. In other words, I end up with a stack high water mark that is 4 TIMES TOO SMALL. This is borne out by setting a breakpoint in usTaskCheckFreeStackSpace() and just doing a memory dump of the memory being scanned.
Am I missing something really silly here, or is this a bona fide bug?
RE: Can usTaskCheckFreeStackSpace() be right?Posted by Richard on October 21, 2008 Yes it 'was' a bug. It got fixed in the SVN copy a few days ago but is not yet in the download.
Apologies for any inconvenience caused.
Regards.
RE: Can usTaskCheckFreeStackSpace() be right?Posted by JohnnyBosc on October 21, 2008 Thanks for the practically instantaneous answer.
Now, if I'd only bothered to read grahamfclark's post from just a couple of days ago...
RE: Can usTaskCheckFreeStackSpace() be right?Posted by JohnnyBosc on October 21, 2008 Richard,
While you're at it can you confirm (or dis-) that the various forms of the macro taskCHECK_FOR_STACK_OVERFLOW() in task.c will in fact detect a stack *underflow* when portSTACK_GROWTH > 0? Granted, not that I know about a whole lot of CPU:s where the stack grows "upwards".
RE: Can usTaskCheckFreeStackSpace() be right?Posted by Richard on October 21, 2008 As per your original question - the current SVN version handles cases where the stack grows up from low memory (portSTACK_GROWTH > 0), but the current release version doesn't.
The SVN repository is public (read only).
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|