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?

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.

Thanks for the practically instantaneous answer. Now, if I’d only bothered to read grahamfclark’s post from just a couple of days ago…

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".

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.