<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 6/5/19 5:30 pm, Amarnath MB wrote:<br>> >> On 3/5/19 7:04 pm, Christian Mauderer wrote:<br>> >> > It's still odd why the PC was on some flash address.<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>> > IRQ is enabled and FIQ is disabled by default in our BSP.<br>> > In my bsp_interrupt_dispatch() routine i'm disabling IRQ in CSPR before<br>> > bsp_interrupt_handler_dispatch() and<br>> > enabling it after, its because of this that both IRQ and FIQ is shown as<br>> > disabled in frame print.<br>> <br>> Sure. I would assume the I bit is set when your BSP wrapper is entered.<br>> <br>> > As i told earlier, we are using uboot (@ 0x0 0ffset in NOR flash) as boot loader<br>> > so the all vectors are in uboot at offsets 0x00, 0x04, 0x08, 0x0C, 0x10, 0x14,<br>> > 0x18, 0x1C. <br>> <br>> Ah ok. What will the cpu fetch when an interrupt happens if you have changed the<br>> state of the NOR flash to program it and it is only returning a status code?<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">Thank you Chris for pointing out the error, this is what that is causing the exception.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">If the NOR flash is in program mode then the CPU fetch during an interrupt will give</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">data exception. I don't know how we missed this condition.<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">> > I am loading RTEMS image into RAM at 0x40008000, so RTEMS exception<br>> > vectors are at addresses 0x40008000, 0x40008004, 0x40008008, 0x4000800C,<br>> > 0x40008010, 0x40008014, 0x40008018 and 0x4000801C respectively. Since when an<br>> > exception happens in RTEMS the ARM core will jump to default vectors in uboot,<br>> > so what i have done is, i have modified the instructions at uboot vectors to<br>> > jump to respective RTEMS vectors so that the exception is handled in RTEMS.<br>> <br>> If an interrupt fires at a point in the NOR programming or NOR status check the<br>> ARM core will see invalid data and you will see unpredictable behaviour.<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">Correct. <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br>> You have couple of options ...<br>> <br>> 1. Mask interrupts at the lowest level in driver around any low level<br>> transactions to the NOR device, for example mask around a command and then<br>> status polling loop or a write and status polling loop.<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">This method is what we had used as a work around as per Christian. <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br>> 2. Rearrange your RAM memory map and set cp15 V (bit 13) to move the vectors to<br>> 0xffff0000 to 0xffff001c. I am not sure if you can remap the RAM or if there is<br>> some on chip memory mapped to this location.<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">It is not possible to remap RAM address in our chip, but we had a TCM memory which we can</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">map to any address. So what i did is, mapped my TCM instruction memory to 0xFFFF0000 and</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">remapped Location of exception vectors from 0x00000000 to
0xFFFF0000 by setting
cp15 V (bit 13).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Along with these changes, i also removed
modifications to the instructions at uboot vectors and my</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">interrupts are working fine.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br>> For me option 2 is better as an exception can always happen and cannot be<br>> masked, you do not need to change uboot which has to be an advantage, plus<br>> interrupts do not need to be masked.<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">Correct, now RTEMS is independent of uboot.<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>> > I don't understand your question, can you please elaborate?<br>> <br>> In some ARM device the SVC mode switches SR and SP registers so an exception<br>> switches stacks and status registers. I have not looked into what the ARM you<br>> have does but it does not matter because I think it is the vector table fetch<br>> which is causing you problems.</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">
Thank you once again for all your support.
</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><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></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></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 7, 2019 at 8:56 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 6/5/19 5:30 pm, Amarnath MB wrote:<br>
>> On 3/5/19 7:04 pm, Christian Mauderer wrote:<br>
>> > It's still odd why the PC was on some flash address.<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>
> IRQ is enabled and FIQ is disabled by default in our BSP.<br>
> In my bsp_interrupt_dispatch() routine i'm disabling IRQ in CSPR before<br>
> bsp_interrupt_handler_dispatch() and<br>
> enabling it after, its because of this that both IRQ and FIQ is shown as<br>
> disabled in frame print.<br>
<br>
Sure. I would assume the I bit is set when your BSP wrapper is entered.<br>
<br>
> As i told earlier, we are using uboot (@ 0x0 0ffset in NOR flash) as boot loader<br>
> so the all vectors are in uboot at offsets 0x00, 0x04, 0x08, 0x0C, 0x10, 0x14,<br>
> 0x18, 0x1C. <br>
<br>
Ah ok. What will the cpu fetch when an interrupt happens if you have changed the<br>
state of the NOR flash to program it and it is only returning a status code?<br>
<br>
> I am loading RTEMS image into RAM at 0x40008000, so RTEMS exception<br>
> vectors are at addresses 0x40008000, 0x40008004, 0x40008008, 0x4000800C,<br>
> 0x40008010, 0x40008014, 0x40008018 and 0x4000801C respectively. Since when an<br>
> exception happens in RTEMS the ARM core will jump to default vectors in uboot,<br>
> so what i have done is, i have modified the instructions at uboot vectors to<br>
> jump to respective RTEMS vectors so that the exception is handled in RTEMS.<br>
<br>
If an interrupt fires at a point in the NOR programming or NOR status check the<br>
ARM core will see invalid data and you will see unpredictable behaviour.<br>
<br>
You have couple of options ...<br>
<br>
1. Mask interrupts at the lowest level in driver around any low level<br>
transactions to the NOR device, for example mask around a command and then<br>
status polling loop or a write and status polling loop.<br>
<br>
2. Rearrange your RAM memory map and set cp15 V (bit 13) to move the vectors to<br>
0xffff0000 to 0xffff001c. I am not sure if you can remap the RAM or if there is<br>
some on chip memory mapped to this location.<br>
<br>
For me option 2 is better as an exception can always happen and cannot be<br>
masked, you do not need to change uboot which has to be an advantage, plus<br>
interrupts do not need to be masked.<br>
<br>
>> Does this variant of ARM have a separate interrupt stack (it seems to<br>
>> have a CPSR)?<br>
> I don't understand your question, can you please elaborate?<br>
<br>
In some ARM device the SVC mode switches SR and SP registers so an exception<br>
switches stacks and status registers. I have not looked into what the ARM you<br>
have does but it does not matter because I think it is the vector table fetch<br>
which is causing you problems.<br>
<br>
Chris<br>
</blockquote></div>