starterware: 2.0.0.7
hardware: beaglebone
ccs: v5
does anyone know how to debug the problem when the processor ends up at 8009e854: EAFFFFFE B loop0 ?
there is no call stack to look at other than one line for loop0.
thanks, jon
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
starterware: 2.0.0.7
hardware: beaglebone
ccs: v5
does anyone know how to debug the problem when the processor ends up at 8009e854: EAFFFFFE B loop0 ?
there is no call stack to look at other than one line for loop0.
thanks, jon
Hi Sujith,
That is certainly true in this case.
The question is, how does one debug this problem? When the processor is stopped while in this loop, the call stack is empty; ie I can't tell how or why I got to this loop. Are there some notes, somewhere, on how to debug in this case?
Thanks, Jon
Hi Jon,
There are no notes or document available for this in StarterWare. You might follow 'ARM level' debugging, putting breakpoint in the abort vectors, then looking at the abort mode link register value to know the instruction which caused the abort, memory dumping etc.
Cheers,
Sujith.
Hi Jon,
The vector table location is at 0x4030FC00. You will be able to find vector table relocation in system_config/armv7a/am335x/startup.c file. You can refer to ARM Architecture Manual for the details on different vectors in the table. To trap the abort, you can put breakpoints at locations I 0x4030FC0C and 0x4030FC10 and then execute the code, check if the execution hits any of these breakpoints.
Regards,
Sujith.