<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">Thank you for all your support.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I will debug on this issue and will keep you posted.<br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="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></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></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2019 at 2:34 PM 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">----- 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: Freitag, 3. Mai 2019 10:37:20<br>
> Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS<br>
<br>
> Hi Christian,<br>
> <br>
> Sorry for the formatting issue, from now onward i will follow like you<br>
> suggested.<br>
> <br>
>>Hello Amarnath,<br>
>><br>
>>just a note in front: Could you try to keep the '>' signs (some mail<br>
> programs show them as a solid line)<br>
>>at the front of the lines intact and don't use ones on your newly written<br>
> lines? Otherwise it's a little<br>
>>hard to see the answers. There's normally no strong formatting<br>
> requirements on this list (also we theoretically have a policy:<br>
>><a href="https://devel.rtems.org/wiki/RTEMSMailingLists#Policies" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/RTEMSMailingLists#Policies</a>) but please try to<br>
> keep the mails readable.<br>
>><br>
>>I tried to fix the indentation signs in my answer below. I hope that I<br>
> caught all your remarks.<br>
> <br>
> Thanks.<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: "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" <<br>
> <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: Freitag, 3. Mai 2019 09:35:27<br>
>>Then it would be best to find the reason for the exception and avoid the<br>
> interrupt lock if possible.<br>
> <br>
> We are discussing this issue with our FPGA team and hope to resolve it soon.<br>
> <br>
>>><br>
>>>> > Flash controller is implemented using the AHB to external SRAM<br>
> interface<br>
>>>> in<br>
>>>> > the Cortex-M System Design Kit and there are no pins shared between<br>
> RAM<br>
>>>> and<br>
>>>> > NOR Flash.  We can't doubt that flash is blocking bus accesses for the<br>
>>>> RAM,<br>
>>>> > because the test executes fine in the uboot running from RAM.<br>
>>>><br>
>>>> So it's a custom FPGA based design? Most likely your RAM and Flash<br>
>>>> controller are both connected to the same system bus (AHB in that<br>
> case). I<br>
>>>> don't know the modules you mentioned but you might want to take a look<br>
> at<br>
>>>> the documentation whether they lock the AHB or not.<br>
>>>><br>
>>>  Yes its a custom FPGA based design. Sure, I will go through the<br>
>>> documentation.<br>
>><br>
>>If the flash controller really blocks all other bus accesses (which would<br>
> be an odd design),<br>
>>you might can move the RAM and Flash to an independent bus or maybe add<br>
> some kind of bus bridge<br>
>>to separate the Flash. But I'm not that deep into the ARM blocks.<br>
> <br>
> Our FPGA team has to see whether it is feasible.<br>
> <br>
>>><br>
>>>> U-Boot most likely doesn't use interrupts. I assume you are waiting for<br>
> a<br>
>>>> flash operation to be finished in some busy wait loop there (polling a<br>
> flag<br>
>>>> or similar). That loop can be fully put into the processor cache (if you<br>
>>>> have one which is quite likely). So in your U-Boot test case, the<br>
> external<br>
>>>> RAM most likely isn't accessed during the flash operations. If you have<br>
> a<br>
>>>> problem<br>
>>>> with conflicting bus accesses you maybe only see them there if you<br>
> disable<br>
>>>> all caches.<br>
>>><br>
>>> You are correct, we are waiting in a loop polling the busy status of NOR<br>
>>> flash. Currently, the caches are enabled in both uboot and RTEMS.<br>
>>><br>
>><br>
>>Maybe you can try to disable them in U-Boot and see whether your behavior<br>
> changes?<br>
>>It could be a bug in disguise if the U-Boot code only works due to caches.<br>
> These are<br>
>>quite nasty because they sometimes depend on the exact position of the<br>
> code. In most<br>
>>cases it works because the loop is in the cache but if for some reason the<br>
> processor<br>
>>has to load a new cache line for the loop it doesn't work. Really hard to<br>
> find because<br>
>>you can change something somewhere completely different and that moves<br>
> your code and<br>
>>triggers a bug.<br>
> <br>
> Ya sure, I will test the same test code on uboot with caches disabled.<br>
> <br>
>>>> In RTEMS on the other hand you are running with enabled interrupts and<br>
>>>> task switches. So RAM access are more or less guaranteed during a longer<br>
>>>> flash operation if you don't lock the interrupts.<br>
>>><br>
>>> Okay, got it.<br>
>>><br>
>>>> ><br>
>>>> > You had mentioned there are a lot of possible reasons for a<br>
>>>> > RTEMS_FATAL_SOURCE_EXCEPTION, is it somewhere documented what all<br>
> reasons<br>
>>>> > can cause this exception. Any references would be very much helpful.<br>
>>>><br>
>>>> Basically for an ARM system, you have that source:<br>
>>>><br>
>>>> cpukit/score/cpu/arm/arm-exception-default.c:24:  rtems_fatal(<br>
>>>> RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame );<br>
>>>><br>
>>>> That is default handler for all exceptions where no extra handler is<br>
>>>> installed. So basically every exception that is listed in the ARM manual<br>
>>>> can be the source.<br>
>>>><br>
>>> Thank you that was helpful.<br>
>>><br>
>><br>
>>If you have a debugger connected, you can set a breakpoint to that handler<br>
> and<br>
>>maybe to _Terminate. Sometimes you can get a source together with the<br>
> reference<br>
>>manual of your processor.<br>
> <br>
> Sure, we will look in to it.<br>
> <br>
>>Maybe take a look at your linker command file or use objdump to analyze<br>
> your elf file. Something seems odd<br>
>>there.<br>
> Below is content of linkcmd<br>
> MEMORY {<br>
>    RAM      : ORIGIN = 0x40008000,  LENGTH = 64M - 512k - 32k<br>
>    RAM_MMU  : ORIGIN = 0x40008000 + 64M - 512k - 32k, LENGTH = 32k<br>
> }<br>
> REGION_ALIAS ("REGION_START", RAM);<br>
> REGION_ALIAS ("REGION_VECTOR", RAM);<br>
> REGION_ALIAS ("REGION_TEXT", RAM);<br>
> REGION_ALIAS ("REGION_TEXT_LOAD", RAM);<br>
> REGION_ALIAS ("REGION_RODATA", RAM);<br>
> REGION_ALIAS ("REGION_RODATA_LOAD", RAM);<br>
> REGION_ALIAS ("REGION_DATA", RAM);<br>
> REGION_ALIAS ("REGION_DATA_LOAD", RAM);<br>
> REGION_ALIAS ("REGION_FAST_TEXT", RAM);<br>
> REGION_ALIAS ("REGION_FAST_TEXT_LOAD", RAM);<br>
> REGION_ALIAS ("REGION_FAST_DATA", RAM);<br>
> REGION_ALIAS ("REGION_FAST_DATA_LOAD", RAM);<br>
> REGION_ALIAS ("REGION_BSS", RAM);<br>
> REGION_ALIAS ("REGION_WORK", RAM);<br>
> REGION_ALIAS ("REGION_STACK", RAM);<br>
> REGION_ALIAS ("REGION_NOCACHE", RAM);<br>
> REGION_ALIAS ("REGION_NOCACHE_LOAD", RAM);<br>
> <br>
> bsp_stack_irq_size = DEFINED (bsp_stack_irq_size) ? bsp_stack_irq_size :<br>
> 4096;<br>
> bsp_stack_abt_size = DEFINED (bsp_stack_abt_size) ? bsp_stack_abt_size :<br>
> 1024;<br>
> <br>
> bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ?<br>
> bsp_section_rwbarrier_align : 1M;<br>
> <br>
<br>
Looks OK to me. It's still odd why the PC was on some flash address. I don't think that I can help you a lot more at the current point. So I'll just let you investigate on that topic some more.<br>
<br>
> *Thank you & Regards,*<br>
> *Amarnath MB*<br>
> <br>
> On Fri, May 3, 2019 at 1:37 PM Christian Mauderer <<br>
> <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br>
> <br>
>> Hello Amarnath,<br>
>><br>
>> just a note in front: Could you try to keep the '>' signs (some mail<br>
>> programs show them as a solid line) at the front of the lines intact and<br>
>> don't use ones on your newly written lines? Otherwise it's a little hard to<br>
>> see the answers. There's normally no strong formatting requirements on this<br>
>> list (also we theoretically have a policy:<br>
>> <a href="https://devel.rtems.org/wiki/RTEMSMailingLists#Policies" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/RTEMSMailingLists#Policies</a>) but please try<br>
>> to keep the mails readable.<br>
>><br>
>> I tried to fix the indentation signs in my answer below. I hope that I<br>
>> caught all your remarks.<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: "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" <<br>
>> <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: Freitag, 3. Mai 2019 09:35:27<br>
>> > Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS<br>
>><br>
>> > On Thu, May 2, 2019 at 3:35 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: "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" <<br>
>> >> <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: Donnerstag, 2. Mai 2019 11:18:48<br>
>> >> > Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS<br>
>> >><br>
>> >> > Hi Christian,<br>
>> >> ><br>
>> >> > As per your suggestion, i tried disabling  global interrupt before my<br>
>> >> erase<br>
>> >> > call and enabling it afterwards. With this setup the test routine is<br>
>> >> > passing without giving exception. So i think, interrupt was the issue<br>
>> >> here.<br>
>> >> ><br>
>> >><br>
>> >> Hello Amarnath,<br>
>> >><br>
>> >> good. Than you have at least a hint toward the problem. I wouldn't see<br>
>> it<br>
>> >> as the solution. Like already discussed, depending on your application,<br>
>> >> this can lead to missed interrupts. If you have a very specific case for<br>
>> >> writing the flash that isn't during your normal operation (for example<br>
>> >> firmware updates) you are most likely fine with that solution. But if<br>
>> you<br>
>> >> write for example log files, you might get a quite unpredictable<br>
>> behavior<br>
>> >> later.<br>
>> >> Hi Christian,<br>
>> >><br>
>> > Thank you for the detailed explanation. Even though we are using NOR<br>
>> > flash for firmware storage, there is a chance that it may be used for log<br>
>> > files later.<br>
>> ><br>
>><br>
>> Then it would be best to find the reason for the exception and avoid the<br>
>> interrupt lock if possible.<br>
>><br>
>> ><br>
>> >> > Flash controller is implemented using the AHB to external SRAM<br>
>> interface<br>
>> >> in<br>
>> >> > the Cortex-M System Design Kit and there are no pins shared between<br>
>> RAM<br>
>> >> and<br>
>> >> > NOR Flash.  We can't doubt that flash is blocking bus accesses for the<br>
>> >> RAM,<br>
>> >> > because the test executes fine in the uboot running from RAM.<br>
>> >><br>
>> >> So it's a custom FPGA based design? Most likely your RAM and Flash<br>
>> >> controller are both connected to the same system bus (AHB in that<br>
>> case). I<br>
>> >> don't know the modules you mentioned but you might want to take a look<br>
>> at<br>
>> >> the documentation whether they lock the AHB or not.<br>
>> >><br>
>> >  Yes its a custom FPGA based design. Sure, I will go through the<br>
>> > documentation.<br>
>><br>
>> If the flash controller really blocks all other bus accesses (which would<br>
>> be an odd design), you might can move the RAM and Flash to an independent<br>
>> bus or maybe add some kind of bus bridge to separate the Flash. But I'm not<br>
>> that deep into the ARM blocks.<br>
>><br>
>> ><br>
>> >> U-Boot most likely doesn't use interrupts. I assume you are waiting for<br>
>> a<br>
>> >> flash operation to be finished in some busy wait loop there (polling a<br>
>> flag<br>
>> >> or similar). That loop can be fully put into the processor cache (if you<br>
>> >> have one which is quite likely). So in your U-Boot test case, the<br>
>> external<br>
>> >> RAM most likely isn't accessed during the flash operations. If you have<br>
>> a<br>
>> >> problem<br>
>> >> with conflicting bus accesses you maybe only see them there if you<br>
>> disable<br>
>> >> all caches.<br>
>> ><br>
>> > You are correct, we are waiting in a loop polling the busy status of NOR<br>
>> > flash. Currently, the caches are enabled in both uboot and RTEMS.<br>
>> ><br>
>><br>
>> Maybe you can try to disable them in U-Boot and see whether your behavior<br>
>> changes? It could be a bug in disguise if the U-Boot code only works due to<br>
>> caches. These are quite nasty because they sometimes depend on the exact<br>
>> position of the code. In most cases it works because the loop is in the<br>
>> cache but if for some reason the processor has to load a new cache line for<br>
>> the loop it doesn't work. Really hard to find because you can change<br>
>> something somewhere completely different and that moves your code and<br>
>> triggers a bug.<br>
>><br>
>> >> In RTEMS on the other hand you are running with enabled interrupts and<br>
>> >> task switches. So RAM access are more or less guaranteed during a longer<br>
>> >> flash operation if you don't lock the interrupts.<br>
>> ><br>
>> > Okay, got it.<br>
>> ><br>
>> >> ><br>
>> >> > You had mentioned there are a lot of possible reasons for a<br>
>> >> > RTEMS_FATAL_SOURCE_EXCEPTION, is it somewhere documented what all<br>
>> reasons<br>
>> >> > can cause this exception. Any references would be very much helpful.<br>
>> >><br>
>> >> Basically for an ARM system, you have that source:<br>
>> >><br>
>> >> cpukit/score/cpu/arm/arm-exception-default.c:24:  rtems_fatal(<br>
>> >> RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame );<br>
>> >><br>
>> >> That is default handler for all exceptions where no extra handler is<br>
>> >> installed. So basically every exception that is listed in the ARM manual<br>
>> >> can be the source.<br>
>> >><br>
>> > Thank you that was helpful.<br>
>> ><br>
>><br>
>> If you have a debugger connected, you can set a breakpoint to that handler<br>
>> and maybe to _Terminate. Sometimes you can get a source together with the<br>
>> reference manual of your processor.<br>
>><br>
>> ><br>
>> >> ><br>
>> >> > Thank you once again for your prompt response, it really saved lot of<br>
>> our<br>
>> >> > time.<br>
>> >> ><br>
>> >> > Below is the exception frame we got,<br>
>> >> > FYI, 0x0 - 0x007FFFFF is NOR Flash and 0x40000000 to 0x7FFFFFFF the<br>
>> RAM.<br>
>> >><br>
>> >> Yust a note: Putting memory at 0 might hides some NULL-pointer accesses.<br>
>> >> If you can do that in your design you might want to think about putting<br>
>> >> some boot ROM there that isn't accessible by the application (for<br>
>> example<br>
>> >> locked via MPU).<br>
>> >><br>
>> > I got it. We have kept uboot at 0x0 and RTEMS at 0x40000 offset of flash,<br>
>> > we have restricted access from application to these uboot and RTEMS<br>
>> > sectors.<br>
>> ><br>
>> >> Of course there can be worse types of memory Flash (which should be<br>
>> mostly<br>
>> >> a read only memory). I had a controller with some RAM there once.<br>
>> Finding<br>
>> >> NULL-pointer accesses on such a system is really nasty.<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>
>> > We are sure that RTEMS is executing entirely from RAM, we are debugging<br>
>> on<br>
>> > this issue.<br>
>><br>
>> Maybe take a look at your linker command file or use objdump to analyze<br>
>> your elf file. Something seems odd there.<br>
>><br>
>> Best regards<br>
>><br>
>> Christian<br>
>><br>
>> >><br>
>> >> Best regards<br>
>> >><br>
>> >> Christian<br>
>> >><br>
>> >> ><br>
>> >> > *Thank you & Regards,*<br>
>> >> > *Amarnath MB*<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On Thu, May 2, 2019 at 12:49 AM Christian Mauderer <<br>
>> >> > <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br>
>> >> ><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: "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" <<br>
>> >> >> <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<br>
>> >> flash<br>
>> >> >> > and then the uboot copies RTEMS application from NOR flash to the<br>
>> 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<br>
>> there<br>
>> >> 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<br>
>> >> including<br>
>> >> >> clock ticks. Most should be processed just a little late but some<br>
>> >> >> interfaces might loose packets or data (depending on the data rate /<br>
>> >> flash<br>
>> >> >> 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<br>
>> >> >> argument. See the example at<br>
>> >> >><br>
>> >><br>
>> <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><br>
>> >> .<br>
>> >> >> Note that for SMP configurations, you might have to use other<br>
>> functions.<br>
>> >> >><br>
>> >> >> But if your application runs entirely from RAM than the bus access<br>
>> >> >> shouldn't be the problem. So the interrupt might isn't the right<br>
>> guess.<br>
>> >> >><br>
>> >> >> Do you have any more information on the exception and where it<br>
>> happens?<br>
>> >> >> Some output or a stack trace from a debugger?<br>
>> >> >><br>
>> >> >> What kind of flash controller is used? Can it block bus accesses for<br>
>> the<br>
>> >> >> 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<br>
>> Suman<br>
>> >> >> 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<br>
>> >> >> ARM926EJ-S<br>
>> >> >> >> > core. I was successful in porting and building BSP for the ARM<br>
>> >> core.<br>
>> >> >> >> ><br>
>> >> >> >> > We are facing a strange issue with the generic NOR flash driver<br>
>> we<br>
>> >> >> have<br>
>> >> >> >> > developed. Our device drivers are designed such that it can be<br>
>> used<br>
>> >> >> with<br>
>> >> >> >> > RTEMS as well as the bare metal programs.<br>
>> >> >> >> > Our driver is working fine in bare metal program (erase, read,<br>
>> >> write<br>
>> >> >> >> > everything), but when we use the driver with RTEMS application<br>
>> and<br>
>> >> >> issue<br>
>> >> >> >> an<br>
>> >> >> >> > erase call, then the application gives<br>
>> >> RTEMS_FATAL_SOURCE_EXCEPTION.<br>
>> >> >> >> ><br>
>> >> >> >> > For testing driver in RTEMS, we have added each test routine as<br>
>> a<br>
>> >> >> 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<br>
>> >> 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<br>
>> 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<br>
>> >> interrupt.<br>
>> >> >> >> Most U-Boot code avoids interrupts. I don't know about your bare<br>
>> >> metal<br>
>> >> >> >> application but maybe in some test application, you don't have too<br>
>> >> much<br>
>> >> >> >> interrupts too. In RTEMS you have most likely at least a periodic<br>
>> >> tick<br>
>> >> >> >> interrupt.<br>
>> >> >> >><br>
>> >> >> >> Do you execute your code from the same flash or do you keep some<br>
>> >> data in<br>
>> >> >> >> the flash? In that case it could be an access error during a flash<br>
>> >> >> erase or<br>
>> >> >> >> write (for example caused by an interrupt). In that case you might<br>
>> >> have<br>
>> >> >> to<br>
>> >> >> >> do a global interrupt disable before you enter certain routines.<br>
>> >> >> >><br>
>> >> >> >> Best regards<br>
>> >> >> >><br>
>> >> >> >> Christian<br>
>> >> >><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>
<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>