RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

Tue May 7 16:02:36 UTC 2019

Hi Chris,

> On 6/5/19 5:30 pm, Amarnath MB 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.
> >
> > 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.
>
> Sure. I would assume the I bit is set when your BSP wrapper is entered.
>
> > 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.
>
> Ah ok. What will the cpu fetch when an interrupt happens if you have
changed the
> state of the NOR flash to program it and it is only returning a status
code?

Thank you Chris for pointing out the error, this is what that is causing
the exception.
If the NOR flash is in program mode then the CPU fetch during an interrupt
will give
data exception. I don't know how we missed this condition.

> > 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.
>
> If an interrupt fires at a point in the NOR programming or NOR status
check the
> ARM core will see invalid data and you will see unpredictable behaviour.

Correct.

> You have couple of options ...
>
> 1. Mask interrupts at the lowest level in driver around any low level
> transactions to the NOR device, for example mask around a command and then
> status polling loop or a write and status polling loop.

This method is what we had used as a work around as per Christian.

> 2. Rearrange your RAM memory map and set cp15 V (bit 13) to move the
vectors to
> 0xffff0000 to 0xffff001c. I am not sure if you can remap the RAM or if
there is
> some on chip memory mapped to this location.

It is not possible to remap RAM address in our chip, but we had a TCM
memory which we can
map to any address. So what i did is, mapped my TCM instruction memory to
0xFFFF0000 and
remapped Location of exception vectors from 0x00000000 to  0xFFFF0000 by
setting  cp15 V (bit 13).
Along with these changes, i also removed modifications to the instructions
at uboot vectors and my
interrupts are working fine.

> For me option 2 is better as an exception can always happen and cannot be
> masked, you do not need to change uboot which has to be an advantage, plus
> interrupts do not need to be masked.

Correct, now RTEMS is independent of uboot.

> >> 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?
>
> In some ARM device the SVC mode switches SR and SP registers so an
exception
> switches stacks and status registers. I have not looked into what the ARM
you
> have does but it does not matter because I think it is the vector table
fetch
> which is causing you problems.

Thank you once again for all your support.

*Thank you & Regards,*
*Amarnath MB*

On Tue, May 7, 2019 at 8:56 AM Chris Johns <chrisj at rtems.org> wrote:

> On 6/5/19 5:30 pm, Amarnath MB 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.
> >
> > 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.
>
> Sure. I would assume the I bit is set when your BSP wrapper is entered.
>
> > 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.
>
> Ah ok. What will the cpu fetch when an interrupt happens if you have
> changed the
> state of the NOR flash to program it and it is only returning a status
> code?
>
> > 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.
>
> If an interrupt fires at a point in the NOR programming or NOR status
> check the
> ARM core will see invalid data and you will see unpredictable behaviour.
>
> You have couple of options ...
>
> 1. Mask interrupts at the lowest level in driver around any low level
> transactions to the NOR device, for example mask around a command and then
> status polling loop or a write and status polling loop.
>
> 2. Rearrange your RAM memory map and set cp15 V (bit 13) to move the
> vectors to
> 0xffff0000 to 0xffff001c. I am not sure if you can remap the RAM or if
> there is
> some on chip memory mapped to this location.
>
> For me option 2 is better as an exception can always happen and cannot be
> masked, you do not need to change uboot which has to be an advantage, plus
> interrupts do not need to be masked.
>
> >> 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?
>
> In some ARM device the SVC mode switches SR and SP registers so an
> exception
> switches stacks and status registers. I have not looked into what the ARM
> you
> have does but it does not matter because I think it is the vector table
> fetch
> which is causing you problems.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20190507/65213f2f/attachment-0002.html>