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


Can portEND_SWITCHING_ISR() cause problems ..

Posted by M Beronius on August 20, 2012
Can portEND_SWITCHING_ISR() cause problems if not called with the result from e.g. xQueueSendToBackFromISR()?

I have a preemptive coldfire target where i have issues with getting caught in vListInsert() sometimes. (a few times a week). Stacks are ok, and all looks to be fine. I end up in vListInsert() when a particular task is checking its message queue.

I have pinpointed that it has something to do with a particular interrupt posting to this message queue.

One thing that I have found, is that the interrupt, sometimes does not take care of the return code from xQueueSendToBackFromISR(), hence no task switch.

I'm going to fix my code, but I wonder if this can cause this kind of error? Gut feeling says no..

RE: Can portEND_SWITCHING_ISR() cause problems ..

Posted by Dave on August 20, 2012
Does the ColdFire port implement interrupt nesting? I think it does, and if so, are you sure the interrupt posting to the queue is running with a priority lower than or equal to whatever configMAX_SYSCALL_INTERRUPT_PRIORITY is set to?

RE: Can portEND_SWITCHING_ISR() cause problems ..

Posted by M Beronius on August 20, 2012
Yes, I have actually set configMAX_SYSCALL_INTERRUPT_PRIORITY to 7, the highest (non maskable) interrupt on the Coldfire. All other interrupts are lower. I have made this table (it is the UART interrupts that can cause this to happen):

/*---------------------------2012-06-27 12:21----------------------------
* Interrupt levels.
* Level Priority Function
* -----------------------------
* 1 0 Kernel context switch
* 1 1 Kernel PIT
* 2 1 DMA0 UART
* 2 2 DMA1 UART
* 2 5 CAN Error
* 2 6 CAN Bus off
* 2 7 FEC Babbling rx
* 3 0 FEC Babbling tx
* 3 1 FEC Bus error
* 3 2 FEC Heart beat error
* 3 3 FEC Late Collision
* 3 4 FEC Collision retry limit
* 3 5 FEC FIFO underrun
* 3 6 FEC Rx buffer
* 3 7 FEC Rx Frame
* 4 0 CAN buffer 0
* 4 1 CAN buffer 1
* 4 2 CAN buffer 2
* 4 3 CAN buffer 3
* 4 4 CAN buffer 4
* 4 5 CAN buffer 5
* 4 6 CAN buffer 6
* 4 7 CAN buffer 7
* 5 0 CAN buffer 8
* 5 1 CAN buffer 9
* 5 2 CAN buffer 10
* 5 3 CAN buffer 11
* 5 4 CAN buffer 12
* 5 5 CAN buffer 13
* 5 6 CAN buffer 14
* 5 7 CAN buffer 15
* 6 1 RTC
* 6 6 UART0
* 6 7 UART1
* 7 Kernel syscall level

RE: Can portEND_SWITCHING_ISR() cause problems ..

Posted by M Beronius on August 22, 2012
OK, so now I had it happen again. I knew it was too good to be true..
This time it was not on my development system, so no new leads to what might have cause this. What makes me confused is that the interrupt isn't very complicated, so I guess I'm overlooking something else.

RE: Can portEND_SWITCHING_ISR() cause problems ..

Posted by M Beronius on August 23, 2012
Caught it in the debugger this morning.

vListInsert() at /home/micke/svn/trunk/controller/FreeRTOS_701/Source/list.c:161 0x7a0
vTaskPlaceOnEventList() at /home/micke/svn/trunk/controller/FreeRTOS_701/Source/tasks.c:1,756 0x154e
xQueueGenericReceive() at /home/micke/svn/trunk/controller/FreeRTOS_701/Source/queue.c:974 0x1dec
os_msg_receive() at /home/micke/svn/trunk/controller/src/os_functions.c:407 0x3764
dsu_thread_main() at /home/micke/svn/trunk/controller/src/control/door_supervisor_task.c:1,709 0xd7e4

Basically what happens is that when arriving to vListInser(), there's one item in the list, and both pxNext and pxPrevious point back to itself, so there's no way of advancements.

pxIteratorvolatile xListItem *0x2000720b
pxNextvolatile struct xLIST_ITEM *0x2000720b
pxPreviousvolatile struct xLIST_ITEM *0x2000720b
pvOwnervoid *0x200071f3
pvContainervoid *0x0

What is actually the correct pointer values when queue contains one item?

The queue is xTasksWaitingToReceive queue.
pvOwner is actually pointing to the same thread that is now trying to insert itself into the queue again, which I guess is compeletely wrong. Is this the reason for ending up in this endless loop, or am I misunderstanding this queue?

RE: Can portEND_SWITCHING_ISR() cause problems ..

Posted by senetti on September 20, 2012
Hi vespaman2,
I´m having the same issue using an LPC1768, have you find a way to solve this issue?
I´m using a binary semaphore to synchronize the reception of CAN messages and the function that parse those messages.
One of the test i did was not to use any more the semaphore and use a simple flag to allow the task to parse or not the messages, in this test i did not have the issue any more, but the problem is that the parsing task runs always and is not good for my application.
Please let me know if find the problem, i will continue doing tests.

RE: Can portEND_SWITCHING_ISR() cause problems ..

Posted by M Beronius on September 20, 2012
My issue turned out to be not using binary semaphore, but you might want to have a look into the follow up thread https://sourceforge.net/projects/freertos/forums/forum/382005/topic/5613033


[ 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