Hi all,
       Do all interrupts get disabled while executing a loop (using rptb
instruction)?? Anyone experience similar issues with rptb instruction? I
think If I add some amount of NOP instructions into the loop the core
services the interrupts otherwise not?. Is this issue documented anywhere?
       I am working on a C55x core in OMAP5910.
Thanks,
Ajith.

Ajith Kutty-

>         Do all interrupts get disabled while executing a loop (using rptb
> instruction)?? Anyone experience similar issues with rptb instruction? I think If I
> add some amount of NOP instructions into the loop the core services the interrupts
> otherwise not?. Is this issue documented anywhere?
>        I am working on a C55x core in OMAP5910.

In the C55x DSP CPU Reference Guide document:

  http://focus.ti.com/lit/ug/spru371f/spru371f.pdf

it says:

  "BRAF is saved and restored with ST1_55 during the context
   switches caused by an interrupt and a return-from-interrupt
   instruction."

-Jeff

Ajith-
>         Thanks for the reply. But I think I didn't clearly stated my point.
>
>         The problem is that all the interrupts seems to be disabled while executing
> a rptb loop with few instructions (>= 2 but <= 4). It is as if INTM bit is set
> before the loop and INTM bit is cleared after the loop. But If I add a few more
> nops (to make the loop bigger.. its consuming MIPS!!!), the interrupts which comes,
> while executing the loop is getting serviced.
>
>         I have checked the list of non-repeatable instructions and I am not using
> any of those. I have this problem as in the system there is an interrupt that
> occurs fairly frequently and I have fairly big loop with execution time comparable
> to the time period of the interrupt. So I can see the interrupt servicing being
> delayed (sometimes even missing an interrupt) while executing this loop.

I would say you need more debug.  First you should post the instructions you are
using in these small loops.  Adding NOPs may be having an alignment effect or some
other inadvertent beneficial consequence that you can obtain some other way.

Second, did you try breaking your RTPB with, say, 3 instructions, into separate
repeat-single instructions?  What happens then?

-Jeff

>  On 12/11/06, Jeff Brower <j...@signalogic.com> wrote:
>
>       Ajith Kutty-
>
>      >         Do all interrupts get disabled while executing a loop (using
>      rptb
>      > instruction)?? Anyone experience similar issues with rptb instruction?
>      I think If I
>      > add some amount of NOP instructions into the loop the core services the
>      interrupts
>      > otherwise not?. Is this issue documented anywhere?
>      >        I am working on a C55x core in OMAP5910.
>
>      In the C55x DSP CPU Reference Guide document:
>
>         http://focus.ti.com/lit/ug/spru371f/spru371f.pdf
>
>      it says:
>
>        "BRAF is saved and restored with ST1_55 during the context
>         switches caused by an interrupt and a return-from-interrupt
>         instruction."
>
>      -Jeff
>

Hi Jeff,
        Thanks for the reply. But I think I didn't clearly stated my point.

        The problem is that all the interrupts seems to be disabled while
executing a rptb loop with few instructions (>= 2 but <= 4). It is as if
INTM bit is set before the loop and INTM bit is cleared after the loop. But
If I add a few more nops (to make the loop bigger.. its consuming MIPS!!!),
the interrupts which comes, while executing the loop is getting serviced.

        I have checked the list of non-repeatable instructions and I am not
using any of those. I have this problem as in the system there is an
interrupt that occurs fairly frequently and I have fairly big loop with
execution time comparable to the time period of the interrupt. So I can see
the interrupt servicing being delayed (sometimes even missing an interrupt)
while executing this loop.
Cheers,
Ajith.

On 12/11/06, Jeff Brower <j...@signalogic.com> wrote:
>
> Ajith Kutty-
>
> >         Do all interrupts get disabled while executing a loop (using
> rptb
> > instruction)?? Anyone experience similar issues with rptb instruction? I
> think If I
> > add some amount of NOP instructions into the loop the core services the
> interrupts
> > otherwise not?. Is this issue documented anywhere?
> >        I am working on a C55x core in OMAP5910.
>
> In the C55x DSP CPU Reference Guide document:
>
>   http://focus.ti.com/lit/ug/spru371f/spru371f.pdf
>
> it says:
>
>   "BRAF is saved and restored with ST1_55 during the context
>    switches caused by an interrupt and a return-from-interrupt
>    instruction."
>
> -Jeff
>

Hi Jeff,
        Following are the loops. I had problems with the following loops and
I had to add nops as you can see.

;circular addressing is set in the following loops.
rptb    pack_burst_soft_end-1
        mov        *ar1+, *ar0+
        mov        *(ar1+t0), *ar0+
        nop
        nop
        nop
        nop
pack_burst_soft_end:

 rptb    get_freq_correction_bits_end - 1
        mov        *ar1+, *ar0+
        mov        *ar1+, *ar2+
        nop
        nop
        nop
        nop
get_freq_correction_bits_end:

This loop I had to change recently and now it looks like the following

rptb    get_freq_bits_end - 1 || mov    *(ar1-t0), ac0

        mov        dbl(*ar1+), ac0
        mov        HI(ac0 << t1),*ar0+
        mov        dbl(*ar1+), ac0
        mov        HI(ac0 << t1),*ar2+
        nop
        nop
        nop
        nop
get_freq_bits_end:

       I believe I have problems with all the loops I have in the software
as I have seen interrupts getting delayed. Only these loops are bigger in
size to create any problems. All loops have circular addressing. I worked on
this problem long time before and at that time i tried to break the loop
into 2 and problem was solved as effectively i am making the loop shorter
and allowing the interrupts to be serviced in between.
       Currently I am living with the nops and will come back and publish if
i have something after more debugging.
Cheers,
Ajith.

On 12/11/06, Jeff Brower <j...@signalogic.com> wrote:
>
> Ajith-
>         Thanks for the reply. But I think I didn't clearly stated my
> point.
>
>         The problem is that all the interrupts seems to be disabled while
> executing a rptb loop with few instructions (>= 2 but <= 4). It is as if
> INTM bit is set before the loop and INTM bit is cleared after the loop. But
> If I add a few more nops (to make the loop bigger.. its consuming MIPS!!!),
> the interrupts which comes, while executing the loop is getting serviced.
>
>         I have checked the list of non-repeatable instructions and I am
> not using any of those. I have this problem as in the system there is an
> interrupt that occurs fairly frequently and I have fairly big loop with
> execution time comparable to the time period of the interrupt. So I can see
> the interrupt servicing being delayed (sometimes even missing an interrupt)
> while executing this loop.
> I would say you need more debug.  First you should post the instructions
> you are using in these small loops.  Adding NOPs may be having an alignment
> effect or some other inadvertent beneficial consequence that you can obtain
> some other way.
>
> Second, did you try breaking your RTPB with, say, 3 instructions, into
> separate repeat-single instructions?  What happens then?
>
> -Jeff
>
>  On 12/11/06, *Jeff Brower* <j...@signalogic.com> wrote:
> >
> >  Ajith Kutty-
> >
> > >         Do all interrupts get disabled while executing a loop (using
> > rptb
> > > instruction)?? Anyone experience similar issues with rptb instruction?
> > I think If I
> > > add some amount of NOP instructions into the loop the core services
> > the interrupts
> > > otherwise not?. Is this issue documented anywhere?
> > >        I am working on a C55x core in OMAP5910.
> >
> > In the C55x DSP CPU Reference Guide document:
> >
> >    http://focus.ti.com/lit/ug/spru371f/spru371f.pdf
> >
> > it says:
> >
> >   "BRAF is saved and restored with ST1_55 during the context
> >    switches caused by an interrupt and a return-from-interrupt
> >    instruction."
> >
> > -Jeff
> >
> >

Ajith-

>         Following are the loops. I had problems with the following loops and
> I had to add nops as you can see.

I don't see a specific thing yet, but got some general ideas.  Did you check this
document:

  http://focus.ti.com/lit/ug/spru652g/spru652g.pdf

There are a couple of advisories there -- while not matching your problem description
exactly -- do seem possibly related.  For example, advisory CPU_116, Interrupted
Nesting of Loops May Stop CPU Execution.  Also do your interrupts have at least 6
NOPs preceding the RETI?  Without those some instructions in repeat blocks may not do
the correct thing (see advisory CPU_99).

What I've found in my experience is the errata / silicon bugs can offer clues as to
what's going on, if you read carefully between the lines.  TI may not yet have
characterized all problems, but the bigger ones for sure, which  may give clues to
the smaller ones.

-Jeff
> ;circular addressing is set in the following loops.
> rptb    pack_burst_soft_end-1
>         mov        *ar1+, *ar0+
>         mov        *(ar1+t0), *ar0+
>         nop
>         nop
>         nop
>         nop
> pack_burst_soft_end:
> 
>  rptb    get_freq_correction_bits_end - 1
>         mov        *ar1+, *ar0+
>         mov        *ar1+, *ar2+
>         nop
>         nop
>         nop
>         nop
> get_freq_correction_bits_end:
> 
> This loop I had to change recently and now it looks like the following
> 
> rptb    get_freq_bits_end - 1 || mov    *(ar1-t0), ac0
> 
>         mov        dbl(*ar1+), ac0
>         mov        HI(ac0 << t1),*ar0+
>         mov        dbl(*ar1+), ac0
>         mov        HI(ac0 << t1),*ar2+
>         nop
>         nop
>         nop
>         nop
> get_freq_bits_end:
> 
>        I believe I have problems with all the loops I have in the software
> as I have seen interrupts getting delayed. Only these loops are bigger in
> size to create any problems. All loops have circular addressing. I worked on
> this problem long time before and at that time i tried to break the loop
> into 2 and problem was solved as effectively i am making the loop shorter
> and allowing the interrupts to be serviced in between.
>        Currently I am living with the nops and will come back and publish if
> i have something after more debugging.
> Cheers,
> Ajith.
> 
> On 12/11/06, Jeff Brower <j...@signalogic.com> wrote:
> >
> > Ajith-
> >
> >
> >         Thanks for the reply. But I think I didn't clearly stated my
> > point.
> >
> >         The problem is that all the interrupts seems to be disabled while
> > executing a rptb loop with few instructions (>= 2 but <= 4). It is as if
> > INTM bit is set before the loop and INTM bit is cleared after the loop. But
> > If I add a few more nops (to make the loop bigger.. its consuming MIPS!!!),
> > the interrupts which comes, while executing the loop is getting serviced.
> >
> >         I have checked the list of non-repeatable instructions and I am
> > not using any of those. I have this problem as in the system there is an
> > interrupt that occurs fairly frequently and I have fairly big loop with
> > execution time comparable to the time period of the interrupt. So I can see
> > the interrupt servicing being delayed (sometimes even missing an interrupt)
> > while executing this loop.
> >
> >
> > I would say you need more debug.  First you should post the instructions
> > you are using in these small loops.  Adding NOPs may be having an alignment
> > effect or some other inadvertent beneficial consequence that you can obtain
> > some other way.
> >
> > Second, did you try breaking your RTPB with, say, 3 instructions, into
> > separate repeat-single instructions?  What happens then?
> >
> > -Jeff
> >
> >  On 12/11/06, *Jeff Brower* <j...@signalogic.com> wrote:
> > >
> > >  Ajith Kutty-
> > >
> > > >         Do all interrupts get disabled while executing a loop (using
> > > rptb
> > > > instruction)?? Anyone experience similar issues with rptb instruction?
> > > I think If I
> > > > add some amount of NOP instructions into the loop the core services
> > > the interrupts
> > > > otherwise not?. Is this issue documented anywhere?
> > > >        I am working on a C55x core in OMAP5910.
> > >
> > > In the C55x DSP CPU Reference Guide document:
> > >
> > >    http://focus.ti.com/lit/ug/spru371f/spru371f.pdf
> > >
> > > it says:
> > >
> > >   "BRAF is saved and restored with ST1_55 during the context
> > >    switches caused by an interrupt and a return-from-interrupt
> > >    instruction."
> > >
> > > -Jeff