Need help figuring out why ARM hits data_abort right after hitting Exception_interrupt

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Aug 19 07:23:14 UTC 2020


On 19/08/2020 09:18, Richi Dubey wrote:

> This mail is in continuation of 
> https://lists.rtems.org/pipermail/devel/2020-August/061446.html.
>
> Right after the check_cpu_allocation test for the last action gets 
> passed (code here 
> <https://github.com/richidubey/rtems/blob/6e455a5d77417dcbc2f00330ebc37a7a143c5384/testsuites/smptests/smpstrongapa01/init.c#L125>), _ARMV4_Exception_interrupt 
> gets called when the timer function finishes.
>
> But soon thereafter _ARMV4_Exception_data_abort_default occurs. Why 
> does that happen? I believe it might have something to do with the 
> fact that T0 (the task that was earlier running on processor 0 and was 
> responsible for running the timer function and later returning to 
> Init) has changed its processor to processor 2 (as we know since the 
> check_cpu_allocation passed).
When you get a data abort exception you destroyed some data structures 
or use data structures wrongly. The goal is to figure out which data 
structure is involved and how is the bad actor. I would use the "bt" 
command when you hit the _ARMV4_Exception_data_abort_default break point.


More information about the devel mailing list