RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

[Christian Mauderer]

----- Ursprüngliche Mail -----
> Von: "Amarnath MB" <amarnath.mb at mistralsolutions.com>
> An: "Christian Mauderer" <christian.mauderer at embedded-brains.de>
> CC: "RTEMS Users" <users at rtems.org>, "Ravi G Patil" <ravigp at mistralsolutions.com>, "Shekhar Suman Singh"
> <shekhar.s at mistralsolutions.com>
> Gesendet: Mittwoch, 1. Mai 2019 17:07:13
> Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

> Hi Christian,
> 
> Thanks for your quick response.
> Our boot process is like, first u-boot will be loaded from the NOR flash
> and then the uboot copies RTEMS application from NOR flash to the RAM.
> After that RTEMS executes entirely from RAM.
> 
> How can i issue a global interrupt disable? Is it using *
> rtems_interrupt_disable(0)*?
> One more doubt, if i issue a global interrupt disable then will there be
> chance that i can miss few clock ticks?
> 
> *Thank you & Regards,*
> *Amarnath MB*
> 

Hello Amarnath,

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.

The rtems_interrupt_disable() function should be called with a level argument. See the example at https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#rtems-interrupt-disable. Note that for SMP configurations, you might have to use other functions.

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.

Do you have any more information on the exception and where it happens? Some output or a stack trace from a debugger?

What kind of flash controller is used? Can it block bus accesses for the RAM? Does your RAM share pins with the flash?

With kind regards

Christian

> 
> 
> On Wed, May 1, 2019 at 8:16 PM Christian Mauderer <
> christian.mauderer at embedded-brains.de> wrote:
> 
>> ----- Ursprüngliche Mail -----
>> > Von: "Amarnath MB" <amarnath.mb at mistralsolutions.com>
>> > An: "RTEMS Users" <users at rtems.org>
>> > CC: "Ravi G Patil" <ravigp at mistralsolutions.com>, "Shekhar Suman Singh"
>> <shekhar.s at mistralsolutions.com>
>> > Gesendet: Mittwoch, 1. Mai 2019 16:28:23
>> > Betreff: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS
>>
>> > Hi All,
>> >
>> > I'm developing RTEMS 5.00 BSP and device drivers for a custom ARM926EJ-S
>> > core. I was successful in porting and building BSP for the ARM core.
>> >
>> > We are facing a strange issue with the generic NOR flash driver we have
>> > developed. Our device drivers are designed such that it can be used with
>> > RTEMS as well as the bare metal programs.
>> > Our driver is working fine in bare metal program (erase, read, write
>> > everything), but when we use the driver with RTEMS application and issue
>> an
>> > erase call, then the application gives RTEMS_FATAL_SOURCE_EXCEPTION.
>> >
>> > For testing driver in RTEMS, we have added each test routine as a custom
>> > shell command using rtems_shell_add_cmd().
>> >
>> > For your info we also tested the same driver with u-boot and it works
>> > fines.
>> > Can anyone guide me on this issue?
>> >
>> > *Thank you & Regards,*
>> > *Amarnath MB*
>> >
>>
>> Hello Amarnath,
>>
>> it's a little hard with the given information to tell you a concrete
>> problem. There are a lot of possible reasons for a
>> RTEMS_FATAL_SOURCE_EXCEPTION.
>>
>> From your description, my guess would be some problem with an interrupt.
>> Most U-Boot code avoids interrupts. I don't know about your bare metal
>> application but maybe in some test application, you don't have too much
>> interrupts too. In RTEMS you have most likely at least a periodic tick
>> interrupt.
>>
>> Do you execute your code from the same flash or do you keep some data in
>> the flash? In that case it could be an access error during a flash erase or
>> write (for example caused by an interrupt). In that case you might have to
>> do a global interrupt disable before you enter certain routines.
>>
>> Best regards
>>
>> Christian

-- 
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.