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

[Richi Dubey]

Got it. Thanks for your answer. I'm working on your suggestion.

On Wed, Aug 19, 2020 at 12:53 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200819/6cb4a7d9/attachment.html>