AM335x StarterWare Data Abort

Hello,

Do you have any idea for this ?
Actually I need to fix it for my customer.

Regards,
Takeshi Matsuzaki

Hi Takeshi,

Can you share some more details like the where exactly does the abort occur? The function name or the instruction where the abort occurs. This would help us to isolate the problem.

Does the application without any changes work correctly on the target? Are you using beaglebone black to run the gpioLedblink example application?

The StarterWare 02.00.01.01 does not support beaglebone black, you need to apply  StarterWare AM335X - 02.00.01.01.patch1 patch which adds beaglebone black support to the StarterWare 02.00.01.01 release.

The link to the above patch is given below http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/starterware/latest/index_FDS.html

Regards

Anant Pai

i Anant,

I was realy waiting for your reply.
I'm using  beaglebone white, and the application without changes works fine.

Open the project of AM335X_StarterWare_02_00_01_01\build\armv7a\cgt_ccs\am335x\beaglebone\gpio
and add
 unsigned char dat;
 unsigned char arr1[2]={0,1};
 unsigned char arr2[2]={2,3};

 dat = 100;
from CCS text editor,

 

project build goes with some warning but I don't care.
launch debugger, connect ccs to beagle bone white, load program, no problems

 

some Assembly Step Into(Ctrl+Shif+F5)

 

Something strange ??

 

and got into AbortHandler()

 

you can reproduce it.

regards,
Takeshi Matsyzaki

 

 

Hello,

Any comments?
this problem is not fixed yet.

Regards,
Takeshi Matsuzaki.

Hi Takeshi,

Sorry for the delayed response.

I updated the gpioLEDBlink.c file with the same changes which you have mentioned in your query. Following are the observations I have regarding these changes affecting the behavior of the program.

1: If I compile the code using gcc compiler (Linaro Toolchain Version 4_7-2012q4) it works correctly on the target without any issues.

2: If I compile the code using TI ARM compiler provided with CCS then I too face the same issues you are facing.

I tried with the following change to the code and it worked for me could you try this change out and see the behavior.

 unsigned char dat;
 unsigned char arr1[2];
 unsigned char arr2[2];

 arr1[0] = 0;
 arr1[1] = 1;
 arr2[0] = 2;
 arr2[1] = 3;

 dat = 100;

Basically i am avoiding assigning any values to the variables during its declaration and this change seems to avoid jumping to the Abort handler.

Regards

Anant Pai

Hi Anant,

Thank you for your responce and stady.
Actuary I am out working now so I can't try the code you mentioned.
But it will avoid the ABORT as you confirmed.

Well, the ABORT code is not out of standrd C coding rule.
Do you think this is a bug of TI ARM compiler ?

Sorry for my brief reply.

Regards,
Takeshi Matsuzaki

Hi! Takeshi san:
I thik the problems are the defination in your array.
Beacuse it show the "question mark" when you build the code. And the mark list is shown by
unsigned char dat;
unsigned char arr1[2]={ 0,1 };
unsigned char arr2[2]={ 2,3 };
I think that the declaration should be globle constant. So that you may throw out of declaration in main()
such as this
unsigned int dat;
const unsigned int arr1[2]={ 0,1 };
const unsigned int arr2[2]={ 2,3 };
int main(void)
{

}
Best regards.
Henry Chou From Quadrep electronics Taiwan

Hi Henry-san,Thank you for your good reply.
Throwing out of declaration will work fine, I will check your code when I come back to my office.
I should not stick to my ABORT code, but..why does my ABORT code go to ABORT?
Your idea and Anant's one will work fine, but my ABORT code should work fine too ?
Regards,Takeshi Matsuzaki