Problem with calling Software Timer functions

Kernel
1

account002 wrote on Sunday, August 31, 2014:

Making a FreeRTOS project for TI Hercules RM48 microcontroller.

Got a problem with Software Timer functions (xTimerCreate(), xTimerReset(), xTimerStop() etc.):
calling any of then inside a task causes a PREFETCH exception of the microcontroller.

Calling them inside main function is ok.

FreeRTOS v.7.4.0

Parameters from FreeRTOSConfig.h

#define configUSE_TIMERS                1
#define configTIMER_TASK_PRIORITY       ( configMAX_PRIORITIES - 2 )
#define configTIMER_QUEUE_LENGTH        10
#define configTIMER_TASK_STACK_DEPTH    ( 128 )

The code

#include "sys_common.h"
#include "het.h"
#include "gio.h"
#include "FreeRTOS.h"
#include "timers.h"
#include "task.h"

void vTask1(void *pvParameters);

uint32 i = 0;

xTimerHandle xTimer1;

// Timer callback function
void vTimerFunction(xTimerHandle xTimer)
{
	// toggle port bits
	gioToggleBit(hetPORT1, i);
	i++;
	if (i>31)
		i=0;

	// restart timer
	xTimerReset(xTimer1, 0);
}

// Main function
void main(void)
{
	// configure port direction (outputs)
	gioSetDirection(hetPORT1, 0xFFFFFFFF);
	// configure port output pins initial value
	gioSetPort(hetPORT1, 0xFFFFFFFF);

	// creating task
	xTaskCreate(vTask1, (const signed char *)"TimerStart", 1024, NULL, (configMAX_PRIORITIES - 3), NULL);

	vTaskStartScheduler();
	while(1);
}

// Task function
void vTask1(void *pvParameters)
{

	xTimer1 = xTimerCreate((const signed char *)"Timer1", 80 / portTICK_RATE_MS, pdFALSE, (void*) 0, vTimerFunction);
	if (xTimer1 != NULL)
		xTimerReset(xTimer1, 0);

	// task self-destruction
	vTaskDelete( NULL );
}

So, calling xTimerCreate causes strange error - prefetch exception.
Moving block

	xTimer1 = xTimerCreate((const signed char *)"Timer1", 80 / portTICK_RATE_MS, pdFALSE, (void*) 0, vTimerFunction);
	if (xTimer1 != NULL)
		xTimerReset(xTimer1, 0);

into the main function (for example, before vTaskStartScheduler()) makes code working properly.

What’s wrong?
Any ideas, please…

2

rtel wrote on Sunday, August 31, 2014:

 xTaskCreate(vTask1,  (const  signed  char  *)"TimerStart",  1024,  NULL,  (configMAX_PRIORITIES  -  3),  NULL);

I assume without creating the timer you find multiple tasks execute
correctly?

If so my first suggestion would have been stack overflow, but you have
given vTask1 a large stack, which I’m almost certain will be fine.
Worth ensuring stack overflow detection is turned on all the same though.

Your FreeRTOS version is moderately old, and I don’t think a lot of the
new configASSERT()s were added until V7.6.0, but it is worth ensuring
that is defined too.

Is the error in xTimerCreate() or xTimerReset()? Can you step through
whichever function it is and let us know on which line the problem occurs.

3

account002 wrote on Sunday, August 31, 2014:

Thank you for response.

Actually the original project includes multiple tasks execution, queues, semaphores - everything works excelent.
After I tried to use Software Timers and got the described error, I wrote a simple version of project, which is shown above.

vTask1 really has a large stack, furthermore in the given project it does nothing, just tries to create timer…
But I’ll still try to check out everything about stack and configASSERT(). Actually, need to read some documentation before…

When I try to call xTimerCreate, the error is quite strange.
It’s not “inside” the function.
Using Assemly Step Into while calling xTimerCreate shows, that prefetch exception occures directly after uP tries to execute instruction BL xTimerCreate… (look at the attached screenshot)…

4

rtel wrote on Sunday, August 31, 2014:

I have never seen such an error. In this case I think you need to look
at the address at which xTimerCreate() is located to see if it is a
valid address in the hope of finding out why a simple branch instruction
causes an abort. Could it be an instruction set change problem if the
timers code is build to pure ARM code? If the address of the function
looks valid then you will have to try and debug the abort from within
the abort handler to determine why the abort occurred.

Regards.