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




Loading

xxxxFromISR functions causing assert

Posted by sfmarks on March 21, 2016

Hello. I am writing a function, which is called both from task as well as from an isr. My FreeRTOS Version is 8.2.0. ~~~~ xHigherPriorityTaskWoken == pdFALSE;

if(TRUE == Task) { xQueueSendToBack(SendQueue,(uint32t*) &sendaStruct, 0); } else { Ticks = xTaskGetTickCountFromISR(); xQueueSendToBackFromISR(SendQueue, (uint32t*) &sendaStruct, &xHigherPriorityTaskWoken) } ~~~~ If I call the xTaskGetTickCountFromISR(); function, then the µController jumps to the vAssertCalled() function. If I comment the line with xTaskGetTickCountFromISR(), the µC jumps to vAssertCalled(), when calling the xQueueSendToBackFromISR() function. The callstack shows me, that the µC jumps to vPortValidateInterruptPriority() and call the macro: configASSERT( ucCurrentPriority >= ucMaxSysCallPriority ); configMAXSYSCALLINTERRUPTPRIORITY has the default value of 191. define configMAXSYSCALLINTERRUPTPRIORITY 191. I also experimented with other values but if the configMAXSYSCALLINTERRUPTPRIORITY value is smaller than 16 (15 is my lowest ISR priority) then the HardFault Handler is called. When the HardFault happen, the call stack shows me this: xPortStartScheduler prvPortStartFirstTask hardfaulthandler The hardfaulthandler is called because xQueueSendToBackFromISR is called. If i comment this line where xQueueSendToBackFromISR will be called, and the configMAXSYSCALLINTERRUPTPRIORITY stays at value of 15, then no hardfault happen.

I hope someone can help me.

Best Regards


xxxxFromISR functions causing assert

Posted by rtel on March 22, 2016

If I call the xTaskGetTickCountFromISR(); function, then the µController jumps to the vAssertCalled() function.

I have just looked at the xTaskGetTickCountFrom() function and the only assert I see is this one:

~~~~ /* RTOS ports that support interrupt nesting have the concept of a maximum system call (or maximum API call) interrupt priority. Interrupts that are above the maximum system call priority are kept permanently enabled, even when the RTOS kernel is in a critical section, but cannot make any calls to FreeRTOS API functions. If configASSERT() is defined in FreeRTOSConfig.h then portASSERTIFINTERRUPTPRIORITYINVALID() will result in an assertion failure if a FreeRTOS API function is called from an interrupt that has been assigned a priority above the configured maximum system call priority. Only FreeRTOS functions that end in FromISR can be called from interrupts that have been assigned a priority at or (logically) below the maximum system call interrupt priority. FreeRTOS maintains a separate interrupt safe API to ensure interrupt entry is as fast and as simple as possible. More information (albeit Cortex-M specific) is provided on the following link: http://www.freertos.org/RTOS-Cortex-M3-M4.html */ portASSERTIFINTERRUPTPRIORITYINVALID(); ~~~~

I'm not sure I can really add much more than the information provided in the comment at the assert point, or the more detailed information on the link provided in the comment. The obvious question then is, not have you tinkered with the configMAXSYSCALLINTERRUPT_PRIORITY setting, but have you set the priority of the interrupt? Please read the link.


xxxxFromISR functions causing assert

Posted by sfmarks on March 22, 2016

Hello. Thank you for your answer. I found the bug. The explanation is: I activated the configAssert macro in freeRTOS. After this I got a failure while colling the xFromISR functions. The problem was, that the configMAXSYSCALLINTERRUPT_PRIORITY was at the default value of 191. I changed the value from 191 to 15, while I worte my post yesterday (I overseen this define before). After I changed the value to 15 xTaskGetTickCountFrom didn't cause any failure. But xQueueSendToBackFromISR crashes, as I wrote. While I was debug my assert failure, I tried to send an other struct. I removed this other struct and tried to send my origin struct, but I forgot to remove the other struct to my origin struct in the function call of xQueueSendToBackFromISR. So I set my origin struct and now the calling of xQueueSendToBackFromISR works.

Can you explain me, why configMAXSYSCALLINTERRUPT_PRIORITY has the value of 191. I don't understand this.

Thank you very much.


xxxxFromISR functions causing assert

Posted by davedoors on March 23, 2016

did you read the link in the code comments in the last post?


[ 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