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

Scheduler problem writing to internal flash

Posted by Corey Paye on January 7, 2013
I am using FreeRTOS v. 7.02 and an EFM32 microcontroller with IAR. I have a task that executes periodically by timing out waiting for a semaphore. The task collects some data and writes it to the internal flash of the microcontroller. Without the write to flash functionality, I have confirmed that the task executes as expected (correct timing, data collection, etc.). However when I put the flash functionality in place, the task executes once (i.e., writes one set of data to flash) and then appears to get lost in the scheduler. From the RTOS plugin I can see that when things get lost the scheduler lists the task as in the running state.

I know that writting to flash means that the code needs to execute from RAM. The EFM32 memory module does this already. I am also disabling interrupts prior to writing to flash and re-enabling when done. Is it possible that by dissabling the interrupts that the RTOS RTC tick interrupt is not executing and therefore the scheduler gets confused?

Any insight would be appreciated.

Thanks.

RE: Scheduler problem writing to internal flash

Posted by Dave on January 7, 2013
The EFM32 is a Cortex-M3 so if interrupts are left disabled for a long time the SysTick will generate lots of tick interrupts but all of them except one will just be lost. That will have the effect of the time kept by the kernel slipping against actual time, but nothing else.

I have had behavior like that before and it turned out that the task was stuck in a polling loop inside a third party driver library function. The plug in said the task was Running, and it was, it was sat in a loop waiting for a bit to get set that never got set.

RE: Scheduler problem writing to internal flash

Posted by Corey Paye on January 7, 2013
Thanks for the reply. So it sounds like missing a SysTick interrupt is not a big deal.

The program is getting hung up in vListInsert at:
for( pxIterator = ( xListItem * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext )

This is within an else statement that warns this point could be reached if 1) Stack overflow 2) Incorrect interrupt priority assignment 3) Calling an API function from within a critical section 4) Using a queue or semaphore before it has been initialized or the scheduler started.

I am pretty sure 2, 3, 4 are not the cause. After the one successful write to flash I used the xTaskGetSchedulerState function to verify that the scheduler was still running. I don't think it is a stack overflow either.

RE: Scheduler problem writing to internal flash

Posted by Dave on January 7, 2013
If the tick interrupt was still executing, and you have stack overflow checking switched on (http://www.freertos.org/Stacks-and-stack-overflow-checking.html) then FreeRTOS would catch a stack overflow, but if the tick interrupt was not running you would have to manually check in the debugger. Manually checking is easy if you have the state viewer plug in because you can have the plug in show the stack high water mark. Do you know what the plug in is reporting as the high water mark for that task?

xTaskGetSchedulerState() is not going to help much here because it will just report what it thinks the state is, in this case, it has been started and is not suspended so it will report that it is running.

How are you disabling interrupts? The proper way is to call taskENTER_CRITICAL() and taskEXIT_CRITICAL() because they will keep a nesting count, but if the flash write driver disables and enables interrupts itself the critical section nest count could get messed up. Do you know if the drivers that write to the flash enables interrupts even if they were disabled when the function is called.

Do the drivers that write to the flash use any interrupts or try to configure the systick timer to generate delays?

RE: Scheduler problem writing to internal flash

Posted by Corey Paye on January 7, 2013
1. In my FreeRTOS Config file I have configCHECK_FOR_STACK_OVERFLOW = 2. I have a vApplicationStackOverflowHook function and I know I am not hitting that. With my plugin the "Min Free Stack" is reported as >256.
2. To disable the interrupts I am using the EM defined function INT_Disable() (and re-enabling them using INT_Enable). The function is supposed to disable interrupts at the CPU level and protect critical sections of code. Like the taskENTER_CRITICAL() and taskEXIT_CRITICAL() functions the EM functions use a counter to track entering and exiting protected sections of code. I did a quick quick and placed taskENTER_CRITICAL() and taskEXIT_CRITICAL() before and after my call to the flash writing function and removed the EM interrupt disabling and enabling functions and got the same behavior.
3. The EM functions that write to flash do not have any interrupts enabled. In their flash manipulation functions I did not see any reference to using the systick.

My plug-in also consistently reports that the "# Waiting Rx" is 2 for the semaphore I am trying to block on after I write to flash. I am not sure how this fits in. It is as though the scheduler thinks there are two tasks waiting for this semaphore. (There are not, only one task uses this particular semaphore.)

RE: Scheduler problem writing to internal flash

Posted by Corey Paye on January 8, 2013
Ok, I think I found the issue though I do not understand why the problem occurred in first place. In my WriteToFlash function I start with INT_Disable and then call after function to find an empty memory location in flash (GetEmpty). Even though in GetEmpty I am just reading from flash I called Int_Disable and Int_Enable. When I return to my write function I call Int_Enable just before exiting. If I remove the second use of Int_Disable, Int_Enable the code works as expected and the RTOS scheduler does not get "corrupted".


[ 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