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.maude...@embedded-brains.de> wrote: > ----- Ursprüngliche Mail ----- > > Von: "Amarnath MB" <amarnath...@mistralsolutions.com> > > An: "RTEMS Users" <users@rtems.org> > > CC: "Ravi G Patil" <rav...@mistralsolutions.com>, "Shekhar Suman Singh" > <shekha...@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.maude...@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. >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
