RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

[Amarnath MB]

Hi Chris,

> On 3/5/19 7:04 pm, Christian Mauderer wrote:
> > It's still odd why the PC was on some flash address.
>
> Yes. The SR (below) is `CPSR = 0x200000d2`. The mode is 0x12 which is
> IRQ mode and both the I and F bits are set which means interrupts are
> masked. I feel the CPSR is in this state with the PC in the NOR flash
> driver code is not right and worth a closer examination.

IRQ is enabled and FIQ is disabled by default in our BSP.
In my bsp_interrupt_dispatch() routine i'm disabling IRQ in CSPR before
bsp_interrupt_handler_dispatch() and
enabling it after, its because of this that both IRQ and FIQ is shown as
disabled in frame print.

As i told earlier, we are using uboot (@ 0x0 0ffset in NOR flash) as boot
loader so the all vectors are in uboot at offsets 0x00, 0x04, 0x08, 0x0C,
0x10, 0x14, 0x18, 0x1C. I am loading RTEMS image into RAM at 0x40008000, so
RTEMS exception vectors are at addresses 0x40008000, 0x40008004,
0x40008008, 0x4000800C, 0x40008010, 0x40008014, 0x40008018 and 0x4000801C
respectively. Since when an exception happens in RTEMS the ARM core will
jump to default vectors in uboot, so what i have done is, i have modified
the instructions at uboot vectors to jump to respective RTEMS vectors so
that the exception is handled in RTEMS.

> Is the fatal error always the same PC?
No, but always the value is in NOR Flash address. Sometimes the PC is at
0x4 which is the undefined_instruction exception, sometimes at non word
aligned addresses like 0x3 and 0x1.

> Is the stack size OK?
We are not specifying the stack size explicitly, we are using the default
values set by RTEMS.

> Does this variant of ARM have a separate interrupt stack (it seems to
> have a CPSR)?
I don't understand your question, can you please elaborate?

> I don't think that I can help you a lot more at the current point. So
> I'll just let you investigate on that topic some more.
>
> Yeah it is hard without more details.

*Thank you & Regards,*
*Amarnath MB*




On Sun, May 5, 2019 at 6:52 AM Chris Johns <chrisj at rtems.org> wrote:

> On 3/5/19 7:04 pm, Christian Mauderer wrote:
> > It's still odd why the PC was on some flash address.
>
> Yes. The SR (below) is `CPSR = 0x200000d2`. The mode is 0x12 which is
> IRQ mode and both the I and F bits are set which means interrupts are
> masked. I feel the CPSR is in this state with the PC in the NOR flash
> driver code is not right and worth a closer examination.
>
> Is the fatal error always the same PC?
>
> Is the stack size OK?
>
> Does this variant of ARM have a separate interrupt stack (it seems to
> have a CPSR)?
>
> I don't think that I can help you a lot more at the current point. So
> I'll just let you investigate on that topic some more.
>
> Yeah it is hard without more details.
>
> Chris
>
> >>>>>>
> >>>>>> *** FATAL ***
> >>>>>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
> >>>>>>
> >>>>>> R0   = 0x00000040 R8  = 0x00100000
> >>>>>> R1   = 0x00080000 R9  = 0x00000001
> >>>>>> R2   = 0x00000048 R10 = 0x4010a3e8
> >>>>>> R3   = 0x00000048 R11 = 0x4011737c
> >>>>>> R4   = 0x00000a00 R12 = 0x00000000
> >>>>>> R5   = 0x00000500 SP  = 0x40100c40
> >>>>>> R6   = 0x00000055 LR  = 0x4000a36c
> >>>>>> R7   = 0x000000aa PC  = 0x003fde80
> >>>>>> CPSR = 0x200000d2 VEC = 0x00000001
> >>>>>> RTEMS version: 5.0.0.
> >>>>>> RTEMS tools: 7.4.0 20181206 (RTEMS 5, RSB
> >>>>>> 40ae056f12e1cbe530f76a3ebd1e2ac745a888ef, Newlib
> >>>>>> dc6e94551f09d3a983afd571478d63a09d6f66fa)
> >>>>>> executing thread ID: 0x08a010002
> >>>>>> executing thread name: Alpi
> >>>>>
> >>>>> Your program counter (PC) points to a Flash address here. Are you
> sure
> >>>>> that your application runs entirely from RAM?
> >>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20190506/e9d67d1c/attachment.html>