Quality RTOS & Embedded Software

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




Loading

FaultISR on Mutex useage

Posted by Maziar on April 23, 2011
Dear people,

I have started a new FreeRTOS project and it is giving me problems with using the Mutex.

I create the mutex by following:

lcd_keypad_shared_pins_mutex = xSemaphoreCreateMutex();
if (lcd_keypad_shared_pins_mutex == NULL)
{
SET_BIT_LOW(PORTD_DATA, PD6);
while(1); // could not create queue
}


This works fine, no error at all.

When i initiate the semaphore by following:
 
xSemaphoreTake(lcd_keypad_shared_pins_mutex, portMAX_DELAY );
.. some code ...
xSemaphoreGive(lcd_keypad_shared_pins_mutex);


At this point the ".. some code .." is not executed and i literally just get Fault_ISR whilst debugging.

Looking into my config file Mutex has been enabled:


#define configUSE_MUTEXES1

#define configUSE_COUNTING_SEMAPHORES 0
#define configUSE_ALTERNATIVE_API 0


I have been debugging for quite a while and i cannot seem to get any further :-(

RE: FaultISR on Mutex useage

Posted by Richard on April 24, 2011
You will have to provide a lot more information before anybody can provide a useful response, otherwise all responses will just be guesses. Please see http://www.freertos.org/FAQ-how-to-use-the-FreeRTOS-support-forum.html

Regards.

RE: FaultISR on Mutex useage

Posted by Maziar on April 24, 2011
Hello richardbarry,

I will try once again, i was a but frustrated after spending alot of hours yesterday, so i should have waited with posting here until i had rested my mind a little.

Development board: Luminary Micro LM3S6965 Ethernet Eval Board
Software: CrossStudio for ARM 2.0
Compiler: GCC
FreeRTOS version: V6.1.1

This morning i attended to make a fresh install of FreeRTOS, as the install before was a import from Red Suite and sadly the problem is still the same.

Anyhow as mentioned i have made a fresh install, and implemented only the code which has been causing the "damage".

main.c:


int main(void) {
portBASE_TYPE create_check = pdTRUE;
setupHardware();

// ---------- Create semaphores/mutex ----------

lcd_keypad_shared_pins_mutex = xSemaphoreCreateMutex();
if (lcd_keypad_shared_pins_mutex == NULL)
{
SET_BIT_LOW(PORTD_DATA, PD6);
while(1); // could not create queue
}

// ---------- Create queues ----------


// ---------- Create tasks ----------

create_check = xTaskCreate( lcd_task, ( signed portCHAR * ) "LCDTASK", USERTASK_STACK_SIZE, NULL, tskIDLE_PRIORITY, NULL);
if (create_check != pdTRUE)
{
SET_BIT_LOW(PORTD_DATA, PD6);
while(1); // could not create task.
}

create_check = xTaskCreate( ui_task, ( signed portCHAR * ) "UITASK", USERTASK_STACK_SIZE, NULL, tskIDLE_PRIORITY, NULL);
if (create_check != pdTRUE)
{
SET_BIT_LOW(PORTD_DATA, PD6);
while(1); // could not create task.
}

/*
* Start the scheduler.
*/
vTaskStartScheduler();

/*
* Will only get here if there was insufficient memory to create the idle task.
*/
return 1;
}



lcd.c (useage of mutex):

xSemaphoreTake(lcd_keypad_shared_pins_mutex, portMAX_DELAY );
// Uninteresting code to drive a LCD
xSemaphoreGive(lcd_keypad_shared_pins_mutex);


FreeRTOSConfig.h


#define configUSE_PREEMPTION1
#define configUSE_IDLE_HOOK0
#define configUSE_TICK_HOOK0
#define configCPU_CLOCK_HZ( ( unsigned portLONG ) 50000000 )
#define configTICK_RATE_HZ( ( portTickType ) 200 )
#define configMINIMAL_STACK_SIZE( ( unsigned portSHORT ) 60 )
#define configTOTAL_HEAP_SIZE( ( size_t ) ( 2800 ) )
#define configMAX_TASK_NAME_LEN( 12 )
#define configUSE_TRACE_FACILITY0
#define configUSE_16_BIT_TICKS0
#define configIDLE_SHOULD_YIELD0
#define configUSE_CO_ROUTINES 0
#define configUSE_MUTEXES1

#define configUSE_COUNTING_SEMAPHORES 0
#define configUSE_ALTERNATIVE_API 0

#define configCHECK_FOR_STACK_OVERFLOW0
#define configUSE_RECURSIVE_MUTEXES1
#define configQUEUE_REGISTRY_SIZE10

#define configMAX_PRIORITIES( ( unsigned portBASE_TYPE ) 5 )
#define configMAX_CO_ROUTINE_PRIORITIES ( 2 )

/* Set the following definitions to 1 to include the API function, or zero
to exclude the API function. */

#define INCLUDE_vTaskPrioritySet1
#define INCLUDE_uxTaskPriorityGet1
#define INCLUDE_vTaskDelete1
#define INCLUDE_vTaskCleanUpResources0
#define INCLUDE_vTaskSuspend1
#define INCLUDE_vTaskDelayUntil1
#define INCLUDE_vTaskDelay1

#define INCLUDE_uxTaskGetStackHighWaterMark1



#define configKERNEL_INTERRUPT_PRIORITY 255

#define configMAX_SYSCALL_INTERRUPT_PRIORITY 191 /* equivalent to 0xa0, or priority 5. */



When i debug the piece of code where i take the Mutex in use and "watch" the Take and Give of the Mutex, straigh after the Take has been executed it goes into FaultISR and basically never reaches the Give.


--- LM3S_Startup_Custom.s -- 138 ---------------------------
DEFAULT_ISR_HANDLER Fault_ISR
E7FE b 0x00000204


I hope my information is a bit more sufficient now, else please let me know i will try to provide as much as possible!


RE: FaultISR on Mutex useage

Posted by Richard on April 24, 2011
The normal source of problems on Cortex-M3 devices is the interrupt priorities. There is some info here on that:
http://www.freertos.org/FAQHelp.html (check item 3). I presume, as you are calling xSemaphoreTake(), that the code is not in an interrupt routine, but are there any interrupts firing in the background (other than the kernel tick)? If so, try stopping the interrupts then running the code.

From what you say, it sounds like the problem is caused in xSemaphoreTake() itself. Is it possible that the lcd_keypad_shared_pins_mutex variable has got corrupted? Or that the structure to which it points has got corrupted? Do you have run time stack checking switched on (does not look like it form the configuration options settings in your post), and the malloc() failed hook defined? It would be worth switching these on as a first step.

If that does not help find the problem, can you step into the xSemaphoreTake() function and see exactly where the problem is happening? Is the task blocking when it attempts to take the semaphore, or is the semaphore already available?

Regards.

RE: FaultISR on Mutex useage

Posted by Maziar on April 24, 2011
“The normal source of problems on Cortex-M3 devices is the interrupt priorities. There is some info here on that:
http://www.freertos.org/FAQHelp.html (check item 3). I presume, as you are calling xSemaphoreTake(), that the code is not in an interrupt routine, but are there any interrupts firing in the background (other than the kernel tick)? If so, try stopping the interrupts then running the code./quote]

By reading the text i understand that i should either set the priority to a higher number or just leave it as is right now (5)?
Theres no interrupts routine in my code right now, i have ripped out everything, except the LCD task and my UI task which only writes text to the LCD right now and nothing else.

“From what you say, it sounds like the problem is caused in xSemaphoreTake() itself. Is it possible that the lcd_keypad_shared_pins_mutex variable has got corrupted? Or that the structure to which it points has got corrupted? Do you have run time stack checking switched on (does not look like it form the configuration options settings in your post), and the malloc() failed hook defined? It would be worth switching these on as a first step.


Thats what im assuming as i go into FAULT_ISR straight after the xSemaphoreTake() is executed. Is there a description concerning "run time stack checking" and the malloc()? I am not quite familiar with this.

“If that does not help find the problem, can you step into the xSemaphoreTake() function and see exactly where the problem is happening? Is the task blocking when it attempts to take the semaphore, or is the semaphore already available?”


None of the tasks run when it attempts to take the Semaphore. But whats the smartest way to check if the semaphore is available whilst debugging?

RE: FaultISR on Mutex useage

Posted by Maziar on April 24, 2011
Sorry i messed up that post! I hope you can figure out the answers underneath the quotes! :-(

RE: FaultISR on Mutex useage

Posted by Maziar on April 24, 2011
Small update, i tried to move the creation of the Mutex from my main.c file to the init of my LCD driver and this is not causing the Fault ISR any longer. What i cant seem to figure out, is a logical explaination on this?

RE: FaultISR on Mutex useage

Posted by Richard on April 24, 2011
[I have deleted the startup file as the license conditions for its distribution are not clear from the code you posted]

“ Is there a description concerning "run time stack checking" and the malloc()? I am not quite familiar with this”


http://www.freertos.org/Stacks-and-stack-overflow-checking.html
http://www.freertos.org/uxTaskGetStackHighWaterMark.html

“Small update, i tried to move the creation of the Mutex from my main.c file to the init of my LCD driver and this is not causing the Fault ISR any longer. What i cant seem to figure out, is a logical explaination on this?”


Where is lcd_keypad_shared_pins_mutex declared? Can you check its value immediately after xSemaphoreCreate() is called, and immediately before xSemaphoreTake() is called to ensure the value is the same (and therefore not corrupted).

Regards.

RE: FaultISR on Mutex useage

Posted by Maziar on April 25, 2011
Hello richard,

Thanks for all your replies, i realised that my error was due to using the semaphore before it was created, i found the error when i went 1 revision backwards in my code, and realised that my LCD screen initiated the semaphore in hardware setup before the creation of the semaphore.

Problem solved!


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




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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

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

OpenRTOS and SafeRTOS