FaultISR on Mutex useage

flashyarm wrote on Saturday, 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_MUTEXES			1
#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 :frowning:

rtel wrote on Sunday, 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.

flashyarm wrote on Sunday, 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_PREEMPTION		1
#define configUSE_IDLE_HOOK			0
#define configUSE_TICK_HOOK			0
#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_FACILITY	0
#define configUSE_16_BIT_TICKS		0
#define configIDLE_SHOULD_YIELD		0
#define configUSE_CO_ROUTINES 		0
#define configUSE_MUTEXES			1
#define configUSE_COUNTING_SEMAPHORES 0
#define configUSE_ALTERNATIVE_API 0
#define configCHECK_FOR_STACK_OVERFLOW	0
#define configUSE_RECURSIVE_MUTEXES		1
#define configQUEUE_REGISTRY_SIZE		10
#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_vTaskPrioritySet		1
#define INCLUDE_uxTaskPriorityGet		1
#define INCLUDE_vTaskDelete				1
#define INCLUDE_vTaskCleanUpResources	0
#define INCLUDE_vTaskSuspend			1
#define INCLUDE_vTaskDelayUntil			1
#define INCLUDE_vTaskDelay				1
#define INCLUDE_uxTaskGetStackHighWaterMark	1
#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 <Fault_ISR>

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

rtel wrote on Sunday, 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.

flashyarm wrote on Sunday, 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?

flashyarm wrote on Sunday, April 24, 2011:

Sorry i messed up that post! I hope you can figure out the answers underneath the quotes! :frowning:

flashyarm wrote on Sunday, 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?

rtel wrote on Sunday, April 24, 2011:

_

_

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._

flashyarm wrote on Monday, 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!