Hi Chris,
> On 6/5/19 5:30 pm, Amarnath MB wrote:
> >> On 3/5/19 7:04 pm, Christian Mauderer wrote:
> >> > It's still odd why the PC was on some flash address.
> >> Yes. The SR (below) is `CPSR = 0x20d2`. The mode is 0x12 which is
> >> IRQ mode and both the I and F bits are set which means int
On 6/5/19 5:30 pm, Amarnath MB wrote:
>> On 3/5/19 7:04 pm, Christian Mauderer wrote:
>> > It's still odd why the PC was on some flash address.
>> Yes. The SR (below) is `CPSR = 0x20d2`. The mode is 0x12 which is
>> IRQ mode and both the I and F bits are set which means interrupts are
>> masked
Hi Chris,
> On 3/5/19 7:04 pm, Christian Mauderer wrote:
> > It's still odd why the PC was on some flash address.
>
> Yes. The SR (below) is `CPSR = 0x20d2`. The mode is 0x12 which is
> IRQ mode and both the I and F bits are set which means interrupts are
> masked. I feel the CPSR is in this s
On 3/5/19 7:04 pm, Christian Mauderer wrote:
It's still odd why the PC was on some flash address.
Yes. The SR (below) is `CPSR = 0x20d2`. The mode is 0x12 which is
IRQ mode and both the I and F bits are set which means interrupts are
masked. I feel the CPSR is in this state with the PC in
; Von: "Amarnath MB"
> > An: "Christian Mauderer"
> > CC: "RTEMS Users" , "Ravi G Patil" <
> rav...@mistralsolutions.com>, "Shekhar Suman Singh"
> >
> > Gesendet: Freitag, 3. Mai 2019 10:37:20
> > Betreff: Re
- Ursprüngliche Mail -
> Von: "Amarnath MB"
> An: "Christian Mauderer"
> CC: "RTEMS Users" , "Ravi G Patil"
> , "Shekhar Suman Singh"
>
> Gesendet: Freitag, 3. Mai 2019 10:37:20
> Betreff: Re: RTEMS_FATAL_SOURCE_
tian.maude...@embedded-brains.de> wrote:
> Hello Amarnath,
>
> just a note in front: Could you try to keep the '>' signs (some mail
> programs show them as a solid line) at the front of the lines intact and
> don't use ones on your newly written lines? Ot
sprüngliche Mail -
> Von: "Amarnath MB"
> An: "Christian Mauderer"
> CC: "RTEMS Users" , "Ravi G Patil"
> , "Shekhar Suman Singh"
>
> Gesendet: Freitag, 3. Mai 2019 09:35:27
> Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in R
gt; rav...@mistralsolutions.com>, "Shekhar Suman Singh"
> >
> > Gesendet: Donnerstag, 2. Mai 2019 11:18:48
> > Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS
>
> > Hi Christian,
> >
> > As per your suggestion, i tried disabling global in
- Ursprüngliche Mail -
> Von: "Amarnath MB"
> An: "Christian Mauderer"
> CC: "RTEMS Users" , "Ravi G Patil"
> , "Shekhar Suman Singh"
>
> Gesendet: Donnerstag, 2. Mai 2019 11:18:48
> Betreff: Re: RTEMS_FATAL_SO
quot;
> > CC: "RTEMS Users" , "Ravi G Patil" <
> rav...@mistralsolutions.com>, "Shekhar Suman Singh"
> >
> > Gesendet: Mittwoch, 1. Mai 2019 17:07:13
> > Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS
>
> > Hi Christian,
>
- Ursprüngliche Mail -
> Von: "Amarnath MB"
> An: "Christian Mauderer"
> CC: "RTEMS Users" , "Ravi G Patil"
> , "Shekhar Suman Singh"
>
> Gesendet: Mittwoch, 1. Mai 2019 17:07:13
> Betreff: Re: RTEMS_FATAL_SOURCE_
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 *
rtem
- Ursprüngliche Mail -
> Von: "Amarnath MB"
> An: "RTEMS Users"
> CC: "Ravi G Patil" , "Shekhar Suman Singh"
>
> 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 ARM926
14 matches
Mail list logo
