# pxCurrentTCB corrupted

**URL:** <https://forums.freertos.org/t/pxcurrenttcb-corrupted/2402>\
**Category:** Kernel\
**Created:** [December 15, 2012, 5:33pm UTC](https://forums.freertos.org/t/pxcurrenttcb-corrupted/2402 "2012-12-15T17:33:19Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 15, 2012, 5:33pm UTC](https://forums.freertos.org/t/pxcurrenttcb-corrupted/2402/1 "2012-12-15T17:33:19Z")

</div>

**[sjackerman](https://sourceforge.net/u/sjackerman/)** wrote on [Saturday, December 15, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/636676b1/#8476):

Working with FreeRTOS v7.1 and Rx62N port.

My application would run for several hours or up to a day then execute the BRK exception handler. I have removed and verified that there are no BRK instructions in my application.

Upon investigating after a invalid BRK exception, I found that somehow the pxCurrentTCB variable was being set to 2 instead of the address of a valid TCB. When this bogus pointer value was used to switch contexts the USP would point to an area of memory that was zeros - which, when excuted is the BRK instruction. All of the tasks stacks and interrupt stack appear to have plenty of room, and I have stack checking enabled.

Using my Renesas E1 emulator I set a event breakpoint for a write to the pxCurrentTCB address with a value of 2. The event captured this bogus write at the end of vTaskSwitchContext() called from within vSoftwareInterruptISR(), prvYieldHandler() at the MVTIPL #1 instruction.

253 void vSoftwareInterruptISR( void )  
254 {  
255 prvYieldHandler();  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89B0 7FA8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \_vSoftwa SETPSW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89B2 7EAF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PUSH.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89B4 FD6A2F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MVFC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USP,R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89B7 60CF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #0CH,R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89B9 FD68F2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MVTC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R15,USP  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89BC E00F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MOV.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ,  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89BE E50F0101&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MOV.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 04H,04H  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89C2 E50F0202&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MOV.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08H,08H  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89C6 62C0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ADD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #0CH,R0  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89C8 7FA9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SETPSW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; U  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89CA 6E1E&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PUSHM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R1-R14  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89CC FD6A3F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MVFC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FPSW,R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89CF 7EAF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PUSH.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89D1 FD1F0F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MVFACHI&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89D4 7EAF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PUSH.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89D6 FD1F2F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MVFACMI&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89D9 6D0F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SHLL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #16,R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89DB 7EAF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PUSH.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89DD FBF2740E0100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MOV.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #00010E74H,R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89E3 ECFF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MOV.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ,R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89E5 E3F0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MOV.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R0,  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89E7 757004&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MVTIPL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #4H  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89EA 05BCC7FF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BSR.A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \_vTaskSwitchContext  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89EE 757001&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MVTIPL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #1H&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<- this is where the pxCurrentTCB=2 event occurred.  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89F1 FBF2740E0100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MOV.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #00010E74H,R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89F7 ECFF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MOV.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ,R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89F9 ECF0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MOV.L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ,R0  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89FB 7EBF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; POP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE89FD FD171F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MVTACLO&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE8A00 7EBF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; POP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE8A02 FD170F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MVTACHI&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE8A05 7EBF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; POP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE8A07 FD68F3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MVTC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R15,FPSW  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE8A0A 6F1F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; POPM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R1-R15  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE8A0C 7F95&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RTE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE8A0E 03&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NOP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE8A0F 03&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NOP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
&nbsp;&nbsp;&nbsp;&nbsp; FFFE8A10 02&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RTS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
256 }

It looks like perhaps the listGET\_OWNER\_OF\_NEXT\_ENTRY(pxTCP, &(pxReadyTasksLists ) is returning an incorrect value ?&nbsp; The value of uxTopReadyPriority = 2 and the contents of pxReadyTasksLists is:

ADDRESS&nbsp;&nbsp;&nbsp; LABEL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASCII  
0001046C&nbsp;&nbsp; \_pxReadyTasksLi&nbsp; 00000001&nbsp;&nbsp; ….  
00010470&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 000079A4&nbsp;&nbsp; .y…  
00010474&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FFFFFFFF&nbsp;&nbsp; ….  
00010478&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 000079A4&nbsp;&nbsp; .y…  
0001047C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 000079A4&nbsp;&nbsp; .y…  
00010480&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00000003&nbsp;&nbsp; ….  
00010484&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000B2FC&nbsp;&nbsp; ….  
00010488&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FFFFFFFF&nbsp;&nbsp; ….  
0001048C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000980C&nbsp;&nbsp; ….  
00010490&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000A55C&nbsp;&nbsp; \…  
00010494&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00000001&nbsp;&nbsp; ….  
00010498&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0001051C&nbsp;&nbsp; ….  
0001049C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FFFFFFFF&nbsp;&nbsp; ….  
000104A0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000ACF4&nbsp;&nbsp; ….  
000104A4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000ACF4&nbsp;&nbsp; ….  
000104A8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00000000&nbsp;&nbsp; ….  
000104AC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 000104B0&nbsp;&nbsp; ….  
000104B0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FFFFFFFF&nbsp;&nbsp; ….  
000104B4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 000104B0&nbsp;&nbsp; ….  
000104B8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 000104B0&nbsp;&nbsp; ….

Any ideas on how to track this down ?&nbsp; I’ve been trying to debug this for several weeks.

Steven J. Ackerman, Consultant  
ACS, Sarasota, Florida  
[http://www.acscontrol.com](http://www.acscontrol.com)

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [December 15, 2012, 6:22pm UTC](https://forums.freertos.org/t/pxcurrenttcb-corrupted/2402/2 "2012-12-15T18:22:53Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, December 15, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/636676b1/#ae11):

Here are some general comments:

+ You mention that the stacks seem to have enough space.&nbsp; Do you also have the stack overflow protection switched on?&nbsp; Be aware that the stack overflow checking only checks the task stack, not the interrupt stack.

+ Are you 100% sure that all interrupts that make use of FreeRTOS API functions have a priority at or below configMAX\_SYSCALL\_INTERRUPT\_PRIORITY (lots of people get this point wrong on Cortex-M3 chips, not surprisingly as the settings are complex, on those, it is much simpler on the RX though).&nbsp; This type of corruption is a symptom of an incorrect value.

+ Have you checked against all the notes on the following page: [http://www.freertos.org/FAQHelp.html](http://www.freertos.org/FAQHelp.html)

+ In your code snipped you note that pxCurrentTCB gets corrupted after the call to vTaskSwitchContext () .&nbsp; That is unlikely because nothing is being written to memory at that point - unless the corruption is occurring from a nested interrupt.&nbsp; What is much more likely is that the corruption is happening **inside** the vTaskSwitchContext() function - because that is where pxCurrentTCB **is**.&nbsp; If you could catch it in there that may provide more useful information.&nbsp; What would be even more useful would be to catch the corruption in the list you reference when it happens, rather than when the corrupt data is used.

+ Are you able to selectively remove pieces of functionality from your code in an attempt to isolate the cause (sometimes that can help, but sometimes changing the execution patter just moves the problem somewhere else).

Regards.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 15, 2012, 7:05pm UTC](https://forums.freertos.org/t/pxcurrenttcb-corrupted/2402/3 "2012-12-15T19:05:31Z")

</div>

**[sjackerman](https://sourceforge.net/u/sjackerman/)** wrote on [Saturday, December 15, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/636676b1/#3c04):

Richard-

First, thank you for your reply.

I have stack overflow protection switched on. I can see the A5(s) in each task’s stack - there is plenty of room in each.

I initialize the interrupt stack in my reset handler - before any C section initialization and main() is called. I’ve looked at the interrupt stack and there is plenty of room there as well.

I will verify that I’m not calling any FreeRTOS API functions from any interrupt handlers above configMAX\_SYSCALL\_INTERUPT\_PRIORITY. This is a possiblity as I do have some interrupts that run at higher priority and there may be an execution path.

I have read and just re-read the FAQHelp again.

The pxCurrentTCB appears to get written to 2 at the line I indicated - at least that is where the emulator stopped execution for the data access write=2 @ pxCurrentTCB event. I’m not sure if the access is pipelined or what delay the emulator introduces - I agree that the MVTIPL #1 instruction should not be the instruction that is corrupting the pxCurrentTCB - it is probably in the list handling at the end of vTaskSwitchContext().&nbsp; I will try to establish a combined event of execution address and data write access to see if I can better establish the place where the write of 2 is occurring.

Desperate to solve this as it is keeping me from selling this product.

Regards,

Steven J. Ackerman, Consultant  
ACS, Sarasota, Florida  
[http://www.acscontrol.com](http://www.acscontrol.com)

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [December 15, 2012, 7:12pm UTC](https://forums.freertos.org/t/pxcurrenttcb-corrupted/2402/4 "2012-12-15T19:12:28Z")

</div>

**[richard\_damon](https://sourceforge.net/u/richard_damon/)** wrote on [Saturday, December 15, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/636676b1/#65ea):

The stopping point may well be delayed due to pipelining in the processor, so if one of the last things done in vTaskSwitchContext is writing the new value, then returning, the return likely starts before the write starts, and thus is allowed to complete (landing you where you did) before the breakpoint hits.

One thing that I can think of that can cause this sort of thing is if you have a TickIdleHook routine that blocks. This can cause the system to not have ANY task to run and then you get into a crash like this.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 15, 2012, 7:36pm UTC](https://forums.freertos.org/t/pxcurrenttcb-corrupted/2402/5 "2012-12-15T19:36:43Z")

</div>

**[sjackerman](https://sourceforge.net/u/sjackerman/)** wrote on [Saturday, December 15, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/636676b1/#507a):

Richard-

Just so I’m clear on this - this approach to handling an interrupt from a source that is higher priority than configMAX\_SYSCALL\_INTERRUPT\_PRIORITY would be OK ? The RTC interrupt has a priority of 5 and occurs once/second. I call xTaskResumeFromISR() from the interrupt handler to wakeup the Timer1S task which reads the current time and queues a message into an event handler queue:

/////////////////////////////////////////////////////////////////////////////  
// local variables  
static uint32\_t&nbsp; time\_counter32bit;  
static EVENT\_MSG msg;  
static tm time;  
static void (\*RTC\_Callback)(void);

/////////////////////////////////////////////////////////////////////////////  
// rtc interrupt handler  
#pragma interrupt Interrupt\_RTC(vect=VECT\_RTC\_PRD)  
void Interrupt\_RTC(void)  
{  
/\* Call the user function iff defined \*/  
if (RTC\_Callback != NULL)  
{  
RTC\_Callback();  
}  
}

/////////////////////////////////////////////////////////////////////////////  
// initialize the RTC  
void RTC\_Init(void (\* callback)(void))  
{  
rtcStop();

/\* periodic interrupt 1Hz \*/  
RTC.RCR1.BIT.PES = 0x6u;

/\* reset RTC \*/  
RTC.RCR2.BIT.RESET = 1;

/\* setup the RTC periodic interrupt callback \*/  
RTC\_Callback = callback;

/\* Disable interrupt requests \*/  
ICU.IER.BIT.IEN\_RTC\_ALM = 0;  
ICU.IER.BIT.IEN\_RTC\_PRD = 0;  
ICU.IER.BIT.IEN\_RTC\_CUP = 0;

/\* Enable RTC periodic interrupt requests \*/  
RTC.RCR1.BIT.PIE = 1;

/\* Enable RTC carry interrupt requests (so we can read it in RTC\_GetTime()) \*/

/\* initialize periodic interrupt priority \*/  
ICU.IPR.BIT.IPR = RTC\_INTERRUPT\_PRIORITY;

/\* Enable periodic interrupt requests \*/  
ICU.IER.BIT.IEN\_RTC\_PRD = 1;

rtcStart();  
}

/\* called from RTC interrupt \*/  
void rtc\_interrupt\_callback(void)  
{  
(void)xTaskResumeFromISR(Timer1SHandle);  
}

/\* task created by TimerRTC\_init \*/  
static void Timer1S(void \*pvParameters)  
{  
EVENT\_MSG msg;

msg.source = MS\_DISPLAY;  
msg.event = ME\_TIME\_UPDATE;

RTC\_Init(rtc\_interrupt\_callback);

for (;😉  
{&nbsp;&nbsp;&nbsp;  
// awoken by xTaskResumeFromISR() in rtc\_interrupt\_callback() above  
vTaskSuspend(NULL);

// a 32 bit counter that is updated every tick ( 1 second)  
time\_counter32bit++;

RTC\_GetTime(&time);

timeUpdated = true;

/\* notify event manager \*/  
msg.param.value = time\_counter32bit;  
(void)xQueueSend(EventQueue, (void \*)&msg, 0UL); /\* RTOS\_USAGE \*/  
}  
}

static void Timer1S(void \*pvParameters);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // The task of Event Manager  
xTaskHandle Timer1SHandle;&nbsp;&nbsp;&nbsp;&nbsp; /\* RTOS\_USAGE \*/

void TimerRTC\_init(void)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
{  
/\* create the timer read task \*/  
(void)xTaskCreate(Timer1S, “t:Time”, configMINIMAL\_STACK\_SIZE, NULL, mainDEMOTASKS\_PRIORITY + 1, &Timer1SHandle);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /\* RTOS\_USAGE \*/

time.tm\_sec = 00;  
time.tm\_min = 45;  
time.tm\_hour = 16;  
time.tm\_am\_pm = T\_PM;  
time.tm\_wday = TUE;  
time.tm\_mday = 26;  
time.tm\_mon = JUN;  
time.tm\_year = 2012;

RTC\_SetTime(&time);

timeUpdated = false;  
}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

Steven J. Ackerman, Consultant  
ACS, Sarasota, Florida  
[http://www.acscontrol.com](http://www.acscontrol.com)

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [December 15, 2012, 7:53pm UTC](https://forums.freertos.org/t/pxcurrenttcb-corrupted/2402/6 "2012-12-15T19:53:58Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, December 15, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/636676b1/#4b15):

Firstly, I hate the function xTaskResumeFromISR().&nbsp; I added it because people requested it, but it can be dangerous if interrupts come in faster than the task that gets resumed can execute from the resume point back to the suspend point (using a semaphore take/give latches events so doesn’t miss them, whereas task suspend/resumes don’t latch events).&nbsp; I don’t think this is the issue in this case though if the interrupt is only coming in once a second it should not be a problem.

> The RTC interrupt has a priority of 5 and occurs once/second.

So the interrupt is calling an API function - you didn’t mention what configMAX\_SYSCALL\_INTERRUPT\_PRIORITY is set to though.&nbsp; If it is 5 or below you should be ok on that point.

From the code it looks like you are using the Renesas compiler.&nbsp; Which version?

Regards.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 15, 2012, 8:07pm UTC](https://forums.freertos.org/t/pxcurrenttcb-corrupted/2402/7 "2012-12-15T20:07:20Z")

</div>

**[sjackerman](https://sourceforge.net/u/sjackerman/)** wrote on [Saturday, December 15, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/636676b1/#10c4):

Richard-

#define configMAX\_SYSCALL\_INTERRUPT\_PRIORITY&nbsp;&nbsp;&nbsp; 4 // 1 (lowest) - 15 (highest)

so I guess that this is the problem… fantastic!&nbsp; I guess that I got confused by the \_FromISR() being allowed from an interrupt and forgot to check the interrupt priority. The low rate of occurence is probably due to the fact that this interrupt and API call only occur once/second.

I’m going to review all of these priorities, make changes and run another test.

I’m running:  
C/C++ compiler package for RX family V.1.02 Release 01 (Update Utility) (3-27-2012 09:14:28)

Regards,

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 17, 2012, 2:21pm UTC](https://forums.freertos.org/t/pxcurrenttcb-corrupted/2402/8 "2012-12-17T14:21:58Z")

</div>

**[sjackerman](https://sourceforge.net/u/sjackerman/)** wrote on [Monday, December 17, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/636676b1/#91d6):

Richard-

This has indeed fixed my problem. My apologies for not catching this whilst perusing the manuals and re-reading the FAQ. My kudos for a great project and your continued excellent support.

Also, thanks for the heads-up on the semaphore vs task suspend/resume.

I hope that you enjoy a great holiday season !

Steven J. Ackerman, Consultant  
ACS, Sarasota, Florida  
[http://www.acscontrol.com](http://www.acscontrol.com)