<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Hi Chris,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">> On 3/5/19 7:04 pm, Christian Mauderer wrote:<br>> > It's still odd why the PC was on some flash address. <br>> <br>> Yes. The SR (below) is `CPSR = 0x200000d2`. The mode is 0x12 which is<br>> IRQ mode and both the I and F bits are set which means interrupts are<br>> masked. I feel the CPSR is in this state with the PC in the NOR flash<br>> driver code is not right and worth a closer examination.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">IRQ is enabled and FIQ is disabled
by default
in our BSP.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">In my bsp_interrupt_dispatch() routine i'm disabling IRQ in CSPR before bsp_interrupt_handler_dispatch() and <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">enabling it after, its because of this that both IRQ and FIQ is shown as disabled in frame print.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">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.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">> Is the fatal error always the same PC?<br>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.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">> Is the stack size OK?<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">We are not specifying the stack size explicitly, we are using the default values set by RTEMS. <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br>> Does this variant of ARM have a separate interrupt stack (it seems to<br>> have a CPSR)?<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I don't understand your question, can you please elaborate?<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br>> I don't think that I can help you a lot more at the current point. So<br>> I'll just let you investigate on that topic some more.<br>> <br>> Yeah it is hard without more details.<br clear="all"></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><p><b><span style="font-family:arial,helvetica,sans-serif"><span style="font-weight:normal">Thank you & Regards,</span></span></b></p><span style="font-family:arial,helvetica,sans-serif"><b><span style="font-weight:bold;font-size:9pt">Amarnath MB</span></b><b><span style="font-weight:bold;font-size:9pt"></span></b></span><br><span style="font-family:arial,helvetica,sans-serif"><b><span style="font-weight:bold;font-size:9pt"></span></b></span><span style="font-family:arial,helvetica,sans-serif"><span style="font-size:9pt"></span></span><span style="font-family:arial,helvetica,sans-serif"> <br></span><span style="font-family:arial,helvetica,sans-serif"> <br></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 5, 2019 at 6:52 AM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/5/19 7:04 pm, Christian Mauderer wrote:<br>
> It's still odd why the PC was on some flash address. <br>
<br>
Yes. The SR (below) is `CPSR = 0x200000d2`. The mode is 0x12 which is <br>
IRQ mode and both the I and F bits are set which means interrupts are <br>
masked. I feel the CPSR is in this state with the PC in the NOR flash <br>
driver code is not right and worth a closer examination.<br>
<br>
Is the fatal error always the same PC?<br>
<br>
Is the stack size OK?<br>
<br>
Does this variant of ARM have a separate interrupt stack (it seems to <br>
have a CPSR)?<br>
<br>
I don't think that I can help you a lot more at the current point. So <br>
I'll just let you investigate on that topic some more.<br>
<br>
Yeah it is hard without more details.<br>
<br>
Chris<br>
<br>
>>>>>><br>
>>>>>> *** FATAL ***<br>
>>>>>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)<br>
>>>>>><br>
>>>>>> R0 = 0x00000040 R8 = 0x00100000<br>
>>>>>> R1 = 0x00080000 R9 = 0x00000001<br>
>>>>>> R2 = 0x00000048 R10 = 0x4010a3e8<br>
>>>>>> R3 = 0x00000048 R11 = 0x4011737c<br>
>>>>>> R4 = 0x00000a00 R12 = 0x00000000<br>
>>>>>> R5 = 0x00000500 SP = 0x40100c40<br>
>>>>>> R6 = 0x00000055 LR = 0x4000a36c<br>
>>>>>> R7 = 0x000000aa PC = 0x003fde80<br>
>>>>>> CPSR = 0x200000d2 VEC = 0x00000001<br>
>>>>>> RTEMS version: 5.0.0.<br>
>>>>>> RTEMS tools: 7.4.0 20181206 (RTEMS 5, RSB<br>
>>>>>> 40ae056f12e1cbe530f76a3ebd1e2ac745a888ef, Newlib<br>
>>>>>> dc6e94551f09d3a983afd571478d63a09d6f66fa)<br>
>>>>>> executing thread ID: 0x08a010002<br>
>>>>>> executing thread name: Alpi<br>
>>>>><br>
>>>>> Your program counter (PC) points to a Flash address here. Are you sure<br>
>>>>> that your application runs entirely from RAM?<br>
>>>>><br>
</blockquote></div></div></div></div></div></div></div>