Data Abort at address 0x1212120c

Kernel
1

nobody wrote on Friday, March 03, 2006:

I’m having a problem running code with freeRTOS 3.2.1 on AT91SAM7X256 with Crossworks compiler

I’ve got 3 tasks running at startup:
1- rs232 handling prio 3
2- usb handling prio 4
3- command processor prio 5

that code runs fine.

If I add a fourth task to start at startup, I
get a data_abort exception at address 0x1212120c

I’ve done a bit of searching but isn’t the initial stack pointer is set to 0x12121212?

I’ve tried adding more stack space to all tasks… no fix

I’ve tried increasing the heap size… no fix

If I comment out xTaskCreate of the fourth task… runs fine

I’ve noticed the data_abort happens when execution get to a vTaskDelay call…

I’ve tried everything but can’t figure this one out. does anyone have any input or suggestions?

thanks.

2

nobody wrote on Friday, March 03, 2006:

The 0x1212120c could be a red herring.  This value is as you say placed onto the stack of a task when the task is created.  Once the stack has been unwound the value will just be left in memory and will legitimately be used by other variables.  It looks like an 8 bit type (set to 0c) is using the same memory location.

Is it possible that the task causing the error is corrupting something?  Have you created a large buffer or array as a stack variable or something like that.

Are you able to post the code for this task?

3

nobody wrote on Friday, March 03, 2006:

Task four has just a framework. here what it was

void vTask4Init( void )
{
}

void vTask4( void *pvParameters )
{
  volatile portCHAR i;
  ( void ) pvParameters;

  vTask4Init();

  for(;:wink:
  {
    i++;
  }
}

4

rtel wrote on Friday, March 03, 2006:

Where is the Delay?  Does vTask4Init() do anything suspicious?

Regards.

5

nobody wrote on Friday, March 03, 2006:

actually the delay is in another task that was running before adding this task to the project.

vTask4Init is exactly as you see it.

6

nobody wrote on Sunday, March 05, 2006:

any ideas?

7

nobody wrote on Monday, March 06, 2006:

From the information so far there is nothing obviously wrong so it is difficult.

Could one of  your exception mode stacks be clashing with your task stack?

Try to examine the heap area (maybe fill the empty area with a known value to see if any of it is getting corrupted).  Also if you single step through the part of the code where the abort is occurring then you may be able to provide more details.

8

nobody wrote on Monday, March 06, 2006:

its the weirdest thing… I’ve stepped through every function, isr and macros I went through and found that I was crashing exactly after I’ve gone into Task4… right there for some reason isAlnum function (which isn’t called anywhere in my code) gets called (traced in assembly) before any variable declares… and from there it crashes.

What I’ve done, I’ve created a new file with the same code, did a build clean then compile/make… and wat do u know? it now works…

sorry if i’ve wasted your time guys… next time I’ll try that first (bowing head in shame)

Thanks for everyones help!