Reply by January 27, 20052005-01-27
Hello,

I've got some news, guys.

Nesting was not the problem.
Stack overflow was not the problem.
ADI libraries for ISR management were not the problem.

This was the problem, my stupid mistake:

In my code, I have routines like this, running on the ISR (at least one of
them):

buffer[counter] = sample;        // Store sample in buffer
counter++;                       // Increment counter
if (counter == MAX_VALUE) {
  flag = true;                   // Set flag if buffer gets full
}
else {
  flag = false;                  // Otherwise, keep it cleared
}

My mistake was that I forgot the "counter = 0;" sentence near "flag = true".
I was doing it in another routine, which does not get triggered at this
point, but in a subsequent call to a function, the calling is controlled by
the "flag".

I simply moved the "counter = 0;" sentence near "flag = true", and
everything works perfectly. Even with interrupt nesting enabled!!

I want to thank all of you for taking your precious time to give me your
valuable advice.

Long live comp.dsp!!

--
Jaime Andr�s Aranguren Cardona
jaac@nospam.sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

"Jim Thomas" <jthomas@bittware.com> escribi&#2013265923; en el mensaje
news:10vfc75plgteu2e@corp.supernews.com...
> Jerry Avins wrote: > > Jaime Andr&#2013265929;s Aranguren Cardona wrote: > >>I placed a hardware breakpoint in the range from 0x50000 to 0x50005 to > >>halt the processor whenever memory in this range is written. The > >>interrupt stopped to occur before the stack was full, so th problem is > >>not being caused by stack overflow, at least not directly. The problem > >>is that the IMASK register, which masks the enabled interrupts, is > >>being written with data that disables my interrupts, so they don't > >>occur anymore.... All of this modifications happens inside the code > >>which is provided on libraries by ADI. > > > > > > My point may yet shed light. Run time is longer at lower interrupt > > rates. What about the number of interrupts? Do they increase? > > > > My guess is that the problem occurs when the higher priority interrupt > pre-empts to lower priority one. This is more likely to happen at > higher rates. Can you turn off the NESTM bit? > > -- > Jim Thomas Principal Applications Engineer Bittware, Inc > jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536 > Quidquid latine dictum sit, altum sonatur. > Whatever is said in Latin sounds profound.
Reply by January 26, 20052005-01-26
Hi,

I apologize for posting the same, several times. This is because of the new
beta service from google groups. Sometimes it fails to confirm that the
message was succesfully sent.

Regards,

--
Jaime Andr&#2013265929;s Aranguren Cardona
jaac@nospam.sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

"Jaime Andr&#2013265929;s Aranguren Cardona" <jaime.aranguren@gmail.com> escribi&#2013265923; en el
mensaje news:1106759966.692019.47020@f14g2000cwb.googlegroups.com...
> Hi Jim, > > Jim Thomas wrote: > > > My guess is that the problem occurs when the higher priority > interrupt > > pre-empts to lower priority one. This is more likely to happen at > > higher rates. Can you turn off the NESTM bit? > > I was waiting for your contribution. It definitely seems to be a > problem with timing... When the SPORT interrupt was running at 240 Hz I > didn't have that problem. > > Will try to disable interrupt nesting (which worked in a great manner > for SPORT0 interrupt at 240 Hz), and will see what happens. > Thanks for your time, > > JaaC >
Reply by January 26, 20052005-01-26
Hi Jim,

Jim Thomas wrote:

> My guess is that the problem occurs when the higher priority
interrupt
> pre-empts to lower priority one. This is more likely to happen at > higher rates. Can you turn off the NESTM bit?
I was waiting for your contribution. It definitely seems to be a problem with timing... When the SPORT interrupt was running at 240 Hz I didn't have that problem. Will try to disable interrupt nesting (which worked in a great manner for SPORT0 interrupt at 240 Hz), and will see what happens. Thanks for your time, JaaC
Reply by January 26, 20052005-01-26
Hi Jim,

Jim Thomas wrote:

> My guess is that the problem occurs when the higher priority
interrupt
> pre-empts to lower priority one. This is more likely to happen at > higher rates. Can you turn off the NESTM bit?
I was waiting for your contribution. It definitely seems to be a problem with timing... When the SPORT interrupt was running at 240 Hz I didn't have that problem. Will try to disable interrupt nesting (which worked in a great manner for SPORT0 interrupt at 240 Hz), and will see what happens. Thanks for your time, JaaC
Reply by January 26, 20052005-01-26
Hi Jim,

Jim Thomas wrote:

> My guess is that the problem occurs when the higher priority
interrupt
> pre-empts to lower priority one. This is more likely to happen at > higher rates. Can you turn off the NESTM bit?
I was waiting for your contribution. It definitely seems to be a problem with timing... When the SPORT interrupt was running at 240 Hz I didn't have that problem. Will try to disable interrupt nesting (which worked in a great manner for SPORT0 interrupt at 240 Hz), and will see what happens. Thanks for your time, JaaC
Reply by January 26, 20052005-01-26
Hi Al,

Al Clark wrote:
> > Jaime Andr=E9s Aranguren Cardona wrote: > > The problem > >> is that the IMASK register, which masks the enabled interrupts, is > >> being written with data that disables my interrupts, so they don't > >> occur anymore.... All of this modifications happens inside the
code
> >> which is provided on libraries by ADI. > > > > Have you looked at the ADI Libraries? I beleive the source is
provided with
> VDSP. You can also look directly at the disassembled code.
Yes, this is the way I discovered that. Looking at the dissasembled code while running a simulation session, I set a watchpoint for halting the DSP when the IMASK register gets written. I can see that the IMASK register gets written when finishing the interrupt handling routine provided in libraries by ADI. The question is: where does the value restored for IMASK come from? I'll further look at the code, thanks for the pointer anyway. BTW, if I recall right, the file is int_cntl.asm, or somethign like that. Source code is provided. I'll examine it. Regards, JaaC
Reply by Jim Thomas January 26, 20052005-01-26
Jerry Avins wrote:
> Jaime Andr&#2013265929;s Aranguren Cardona wrote: >>I placed a hardware breakpoint in the range from 0x50000 to 0x50005 to >>halt the processor whenever memory in this range is written. The >>interrupt stopped to occur before the stack was full, so th problem is >>not being caused by stack overflow, at least not directly. The problem >>is that the IMASK register, which masks the enabled interrupts, is >>being written with data that disables my interrupts, so they don't >>occur anymore.... All of this modifications happens inside the code >>which is provided on libraries by ADI. > > > My point may yet shed light. Run time is longer at lower interrupt > rates. What about the number of interrupts? Do they increase? >
My guess is that the problem occurs when the higher priority interrupt pre-empts to lower priority one. This is more likely to happen at higher rates. Can you turn off the NESTM bit? -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536 Quidquid latine dictum sit, altum sonatur. Whatever is said in Latin sounds profound.
Reply by Al Clark January 26, 20052005-01-26
> Jaime Andr&#2013265929;s Aranguren Cardona wrote:
The problem
>> is that the IMASK register, which masks the enabled interrupts, is >> being written with data that disables my interrupts, so they don't >> occur anymore.... All of this modifications happens inside the code >> which is provided on libraries by ADI. >
Have you looked at the ADI Libraries? I beleive the source is provided with VDSP. You can also look directly at the disassembled code. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
Reply by Jerry Avins January 25, 20052005-01-25
Jaime Andr&#2013265929;s Aranguren Cardona wrote:

  ...

> I placed a hardware breakpoint in the range from 0x50000 to 0x50005 to > halt the processor whenever memory in this range is written. The > interrupt stopped to occur before the stack was full, so th problem is > not being caused by stack overflow, at least not directly. The problem > is that the IMASK register, which masks the enabled interrupts, is > being written with data that disables my interrupts, so they don't > occur anymore.... All of this modifications happens inside the code > which is provided on libraries by ADI.
My point may yet shed light. Run time is longer at lower interrupt rates. What about the number of interrupts? Do they increase? Is anything in TI's code doing indirectly addressed writes? Id the pointer indexed from a table? Does the code run off the end of the table? Jerry -- Engineering is the art of making what you want from things you can get. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
Reply by January 25, 20052005-01-25
Hi Jerry,

Jerry Avins wrote:
> I don't know what the problem is, but this observation might be
helpful:
> > Mice and elephants have about the same lifespan, not in years, but in > heartbeats. When you slow the interrupt rate, it takes more time for
the
> system to bomb. Does it take more interrupts? Do I smell stack
overflow? I also thought of stack overflow. According to my memorymap (LDF) it goes from 0x50000 to 0x50FFF, and fills upwards. I placed a hardware breakpoint in the range from 0x50000 to 0x50005 to halt the processor whenever memory in this range is written. The interrupt stopped to occur before the stack was full, so th problem is not being caused by stack overflow, at least not directly. The problem is that the IMASK register, which masks the enabled interrupts, is being written with data that disables my interrupts, so they don't occur anymore.... All of this modifications happens inside the code which is provided on libraries by ADI. Anyway, I'll check the stack issue again, and will let you know. Any further suggestion? Kindest regards, JaaC
> > Jerry > -- > Engineering is the art of making what you want from things you can
get.
>
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF