RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

[Amarnath MB]

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*



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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20190501/9bf1719e/attachment-0002.html>