Got it. Thanks for your answer. I'm working on your suggestion. On Wed, Aug 19, 2020 at 12:53 PM Sebastian Huber < sebastian.hu...@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. >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
