RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

[Chris Johns]

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