Richard, After my target runs for awhile – I get a stoppage: My call stack looks like this: main() prvIdleTask(_A_IE1(0x0) [PC=Memory:0x3082] In main: …     vTaskStartScheduler(); // shouldn’t get past this point unless a task calls vTaskEndScheduler() // Note – I have a breakpoint on this first NOOP but it doesn’t stop there         __no_operation();         __no_operation();         while (1) {         __no_operation();         __no_operation(); // I have a breakpoint on the 2nd NOOP (just above) and the debugger stops here.   // turn Debug LED’s on:         asm("bis.b     #0x80,&0x1d");                    asm("bis.b     #0x01,&0x1d");             } I run the Idle Hook as well – this (crash) doesn’t always happen either – but I assume all of my targets will eventually fail. What are some reasons this can happen?  I know this may seem a bit nebulous – but the Scheduler is exiting (even though the vTaskEndScheduler() function) – isn’t being called. It seems that somehow the return address from the vTaskStartScheduler(); call is getting popped into the PC and executed – or at least an address+2 or something. From my linker map file: DATA16_Z   Relative segment, address: 3082 – 3085 (0x4 bytes), align: 1   Segment part 5.             Intra module refs:   pvPortMalloc            LOCAL                   ADDRESS                    =====                   =======                    xEnd                    3082 I’m using heap_2.c as my memory manager: /* xEnd is used to mark the end of the list of free blocks. */    I’m also saying that the IdleTask & Hook should yield – it seems this problem may be occurring during that. Thanks In Advance, John W.

I understand not the sentense "I’m also saying that the IdleTask & Hook should yield".  The idle task must always be in a ready state and not blocked so just yield must be ok.  Sorry to state obvious but sometimes it can help.  Otherwise is the idle task stack causing a problem under some interrupt conditions?

Idle task doesn’t block – correct. I think the Idle Task Stack may be causing a problem under some interrupt conditions – yes. Thanks, John