Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training


PIC32 - crash during context switch

Posted by Piero B on November 12, 2010
Hi all.

we found a very strange situation.

We had PIC32 in crash, and we verified the following:

- Stack pointer was on flash address (it pointed to xISRStack address)
- using tracer, it seemed that micro stops inside PORT_SAVE_CONTEXT code, after this instruction:
/* Swap to the system stack. */
lasp, xISRStackTop
- changing a little the application code (even adding a NOP), we remove crash, probably because timing changed, and critical situation didn't occur

we are using:
- FreeRTOS V6.0.2
- configMAX_SYSCALL_INTERRUPT_PRIORITY0x06 and we have different ISR routines that use RTOS api and work using lower priority

It is only a theory (we should be in wrong): our doubts are related to macro portSAVE_CONTEXT, expecially in these rows:

/* Swap to the system stack. */
lasp, xISRStackTop
lwsp, (sp)

What's happen if an interrupt occurs in the middle of these instructions? SP will be corrupted as we found?
Could be useful to wrap these instructions with critical sections, blocking INTERRUPTS?

We will wait some feedbacks

Thanks to all in advance

RE: PIC32 - crash during context switch

Posted by MEdwards on November 12, 2010
Are you sure that interrupts are enabled when these lines are executed. The MIPS core will disable all interrupts when an interrupt is taken, and then the scheduler selectively enables and disables up to a certain priority value during the context switch code. I would be surprised if the lines you have quoted are executed while interrupts can clobber the register values.

RE: PIC32 - crash during context switch

Posted by Piero B on November 12, 2010
Thanks for your reply.

We think the same, but reading the code, it seems that scheduler enables irq BEFORE these lines:

/* Enable interrupts above the current priority. */
srlk0, k0, 0xa
ins k1, k0, 10, 6
insk1, zero, 1, 4

/* s5 is used as the frame pointer. */
adds5, zero, sp

/* Check the nesting count value. */
lak0, uxInterruptNesting
lws6, (k0)

/* If the nesting count is 0 then swap to the the system stack, otherwise
the system stack is already being used. */
bnes6, zero, .+20

/* Swap to the system stack. */
lasp, xISRStackTop
lwsp, (sp)

At this point,
Richard, can you help us? any idea regarding the crash?


RE: PIC32 - crash during context switch

Posted by Richard on November 12, 2010
I've just had a look at the code, and I think edwards3 could be right here.

In the code you are referring to, my quick inspection (which I'm willing to be proven wrong on) is that:

0) Interrupt are globally disabled on interrupt entry.
1) K1 is loaded with the priority of the executing interrupt.
2) The interrupt nesting count is inspected and if it is 0 a swap is made to the system stack - this is where the code you highlighted is executed.
3) The interrupt nesting count is incremented and saved.
4) Only then is the interrupt mask set to that of the currently executing interrupt - effectively enabling interrupts above the priority of the currently executing interrupt. In my 6.1.0 version this is done on line 106 by the instruction "mtc0 k1, _CP0_STATUS" (remember the interrupt priority was saved into k1).

I hope this clears this up. Please tell me if you still think there is an issue.


RE: PIC32 - crash during context switch

Posted by Richard on November 12, 2010
Just saw your next post - interrupt are enabled after the snippet you have posted (see my first post). The code you show only loads K1 with the value that the interrupt mask is later set to. The comment is perhaps a bit misleading.


RE: PIC32 - crash during context switch

Posted by Piero B on November 12, 2010
Hi Richard
Thanks for your feedback... now the code is more clear.

But we are at the beginning again:
we don't know the reason of crash.

Current code hasn't this bug (or, it could be hidden in same operations sequence - we saw it in previous cose doing always the same operations an our board). We saw mcu locked, with PC and to a strange address (it should be address of general exception), cause register didn't help us, EPC provide an address of apiece of code that has run a lot of time without trouble, and all around (vars, pointers) seemed ok. The only rilevant thing is ths SP that pointed to flash (task and ISR stacks has free space, no overflows).

I really don't know what i ahve to search. And i'm worried that bug can happen again.
Any idea to debug it if we will see it again?


PIC32 - crash during context switch

Posted by jussippi on April 14, 2014


Have you seen this problem again?

We run into similar problem with FreeRTOS 7.6.0 and PIC32MX795F512L.

First indication was that the code stopped in general exception, reason was "Bus Error Exception (instruction fetch)". EPC register was "A5A5A5A5" which is the value the stack initialized to. Task SP was updated to invalid value and therefore program counter got value where no memory existed.

Further studying led us to situation that we found a task stack pointer pointing to ISR stack area.

This problem vanishes by altering the code / timing. Which is very scary, unless we understand the reason.

There seems to be something seriously wrong in FreeRTOS scheduler / interrupt handling...



PIC32 - crash during context switch

Posted by rtel on April 14, 2014

Most likely cause is misuse of the API with respect to interrupts.

Are you following the instructions in the "interrupt service routines" section of the following page: http://www.freertos.org/portPIC32MIPSMK4.html - in particular, are you 100% certain that you are not using an interrupt safe FreeRTOS API function from an interrupt that has a priority above whatever you have set configMAXSYSCALLINTERRUPTPRIORITY to?

Are you correctly wrapping any interrupts with the provided asm code?

Have you read the following page of the FAQ and ensured you are following the information contained there (like not calling functions that don't end in "from isr" from an interrupt. http://www.freertos.org/FAQHelp.html



PIC32 - crash during context switch

Posted by jussippi on April 15, 2014


Thanks for the hints - although we had gone through all of that. :)

Anyway, you were right. We had a callback from the old SW interrupt, which was using generic function to read data. That function now uses a mutex (non ISR) for data protection... Which caused all the bad things.



[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.

Free TCP/IP and file system demos for the RTOS

Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists