<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Hi Christian,</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 per your suggestion, i tried disabling
global interrupt before my erase call and enabling it afterwards. With this setup the test routine is passing without giving exception. So i think, interrupt was the issue here.</div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">Flash controller is implemented using
<span style="line-height:115%" lang="EN-US">the
AHB to external SRAM interface in the Cortex-M System Design Kit and there are no pins shared between RAM and NOR Flash. We can't doubt that flash is blocking bus accesses for the RAM, because the test executes fine in the uboot running from RAM.
</span></font>
</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">You had mentioned there are a lot of possible reasons for a RTEMS_FATAL_SOURCE_EXCEPTION, is it somewhere documented what all reasons can cause this exception. Any references would be very much helpful.<br></div></div><div dir="ltr"><br></div><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">Thank you once again for your prompt response, it really saved lot of our time.<br></div></div><div dir="ltr"><br></div><div dir="ltr"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Below is the</span> exception frame
we got<span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">,</span><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">FYI, 0x0 - 0x007FFFFF is NOR Flash and 0x40000000 to 0x7FFFFFFF the RAM.</div>
</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"></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><span style="font-family:monospace,monospace">*** 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 40ae056f12e1cbe530f76a3ebd1e2ac745a888ef, Newlib dc6e94551f09d3a983afd571478d63a09d6f66fa)<br>executing thread ID: 0x08a010002<br>executing thread name: Alpi</span><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"><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 Thu, May 2, 2019 at 12:49 AM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</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"><br>
----- Ursprüngliche Mail -----<br>
> Von: "Amarnath MB" <<a href="mailto:amarnath.mb@mistralsolutions.com" target="_blank">amarnath.mb@mistralsolutions.com</a>><br>
> An: "Christian Mauderer" <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
> CC: "RTEMS Users" <<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>>, "Ravi G Patil" <<a href="mailto:ravigp@mistralsolutions.com" target="_blank">ravigp@mistralsolutions.com</a>>, "Shekhar Suman Singh"<br>
> <<a href="mailto:shekhar.s@mistralsolutions.com" target="_blank">shekhar.s@mistralsolutions.com</a>><br>
> Gesendet: Mittwoch, 1. Mai 2019 17:07:13<br>
> Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS<br>
<br>
> Hi Christian,<br>
> <br>
> Thanks for your quick response.<br>
> Our boot process is like, first u-boot will be loaded from the NOR flash<br>
> and then the uboot copies RTEMS application from NOR flash to the RAM.<br>
> After that RTEMS executes entirely from RAM.<br>
> <br>
> How can i issue a global interrupt disable? Is it using *<br>
> rtems_interrupt_disable(0)*?<br>
> One more doubt, if i issue a global interrupt disable then will there be<br>
> chance that i can miss few clock ticks?<br>
> <br>
> *Thank you & Regards,*<br>
> *Amarnath MB*<br>
> <br>
<br>
Hello Amarnath,<br>
<br>
with a global interrupt lock, all kinds of events can be missed including clock ticks. Most should be processed just a little late but some interfaces might loose packets or data (depending on the data rate / flash access times). So if not necessary it's not a good solution.<br>
<br>
The rtems_interrupt_disable() function should be called with a level argument. See the example at <a href="https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#rtems-interrupt-disable" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#rtems-interrupt-disable</a>. Note that for SMP configurations, you might have to use other functions.<br>
<br>
But if your application runs entirely from RAM than the bus access shouldn't be the problem. So the interrupt might isn't the right guess.<br>
<br>
Do you have any more information on the exception and where it happens? Some output or a stack trace from a debugger?<br>
<br>
What kind of flash controller is used? Can it block bus accesses for the RAM? Does your RAM share pins with the flash?<br>
<br>
With kind regards<br>
<br>
Christian<br>
<br>
> <br>
> <br>
> On Wed, May 1, 2019 at 8:16 PM Christian Mauderer <<br>
> <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br>
> <br>
>> ----- Ursprüngliche Mail -----<br>
>> > Von: "Amarnath MB" <<a href="mailto:amarnath.mb@mistralsolutions.com" target="_blank">amarnath.mb@mistralsolutions.com</a>><br>
>> > An: "RTEMS Users" <<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
>> > CC: "Ravi G Patil" <<a href="mailto:ravigp@mistralsolutions.com" target="_blank">ravigp@mistralsolutions.com</a>>, "Shekhar Suman Singh"<br>
>> <<a href="mailto:shekhar.s@mistralsolutions.com" target="_blank">shekhar.s@mistralsolutions.com</a>><br>
>> > Gesendet: Mittwoch, 1. Mai 2019 16:28:23<br>
>> > Betreff: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS<br>
>><br>
>> > Hi All,<br>
>> ><br>
>> > I'm developing RTEMS 5.00 BSP and device drivers for a custom ARM926EJ-S<br>
>> > core. I was successful in porting and building BSP for the ARM core.<br>
>> ><br>
>> > We are facing a strange issue with the generic NOR flash driver we have<br>
>> > developed. Our device drivers are designed such that it can be used with<br>
>> > RTEMS as well as the bare metal programs.<br>
>> > Our driver is working fine in bare metal program (erase, read, write<br>
>> > everything), but when we use the driver with RTEMS application and issue<br>
>> an<br>
>> > erase call, then the application gives RTEMS_FATAL_SOURCE_EXCEPTION.<br>
>> ><br>
>> > For testing driver in RTEMS, we have added each test routine as a custom<br>
>> > shell command using rtems_shell_add_cmd().<br>
>> ><br>
>> > For your info we also tested the same driver with u-boot and it works<br>
>> > fines.<br>
>> > Can anyone guide me on this issue?<br>
>> ><br>
>> > *Thank you & Regards,*<br>
>> > *Amarnath MB*<br>
>> ><br>
>><br>
>> Hello Amarnath,<br>
>><br>
>> it's a little hard with the given information to tell you a concrete<br>
>> problem. There are a lot of possible reasons for a<br>
>> RTEMS_FATAL_SOURCE_EXCEPTION.<br>
>><br>
>> From your description, my guess would be some problem with an interrupt.<br>
>> Most U-Boot code avoids interrupts. I don't know about your bare metal<br>
>> application but maybe in some test application, you don't have too much<br>
>> interrupts too. In RTEMS you have most likely at least a periodic tick<br>
>> interrupt.<br>
>><br>
>> Do you execute your code from the same flash or do you keep some data in<br>
>> the flash? In that case it could be an access error during a flash erase or<br>
>> write (for example caused by an interrupt). In that case you might have to<br>
>> do a global interrupt disable before you enter certain routines.<br>
>><br>
>> Best regards<br>
>><br>
>> Christian<br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax: +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div>