Problem with interrupts on ADSP-21161N

Hi,

I'm working on ADSP-21161N rev 1.1. I should run SPORT0 interrutps at
9600 Hz, setting the dividers to 24 for SCLK at 2.083333333 Mhz and
217, thus having SPORT0 interrupts at 9600.6144 Hz. Additionally I
should run Timer interrupts at different frequencies, from 0.5 Hz to 40
Hz.

I have found that when I set the Timer interrupts to happen at around
10 Hz or faster, the system runs fine for a short while, and suddenly
the interrupts stop happening, sometimes both the Timer and Sport0
interrupts, other times either one. But if I configure it to happn at a
lower rate the system seems to be more stable, but not working
perfectly (still interrupts stop happening, but take longer to behave
like this).

With the aid of the emulator I can see that the IMASK register is being
written with values which mask the interrupts, that's the reason why
they stop happening. But that overwritting of the IMASK register
happens within library functions, as I could find by running a
simulation session and setting watchpoints to halt when the IMASK
register is written. The library function seems to be the one in charge
of handling the interrupts on the ADSP-21161N

My program is completely in C. I set the interrupts using the
interrupt() function. I tried the "non self-modifying" version of the
interrupt() function, and also the "fast" and "super fast" vesions,
niether one seems to help.

I activate the lower priority Timer interrupt, and interrupt nesting is
on too.

What can be wrong? How to solve it?
Thank you for your time and help.

Regards,

JaaC

Jaime Andr�s Aranguren Cardona wrote:

> Hi,
> 
> I'm working on ADSP-21161N rev 1.1. I should run SPORT0 interrutps at
> 9600 Hz, setting the dividers to 24 for SCLK at 2.083333333 Mhz and
> 217, thus having SPORT0 interrupts at 9600.6144 Hz. Additionally I
> should run Timer interrupts at different frequencies, from 0.5 Hz to 40
> Hz.
> 
> I have found that when I set the Timer interrupts to happen at around
> 10 Hz or faster, the system runs fine for a short while, and suddenly
> the interrupts stop happening, sometimes both the Timer and Sport0
> interrupts, other times either one. But if I configure it to happn at a
> lower rate the system seems to be more stable, but not working
> perfectly (still interrupts stop happening, but take longer to behave
> like this).
> 
> With the aid of the emulator I can see that the IMASK register is being
> written with values which mask the interrupts, that's the reason why
> they stop happening. But that overwritting of the IMASK register
> happens within library functions, as I could find by running a
> simulation session and setting watchpoints to halt when the IMASK
> register is written. The library function seems to be the one in charge
> of handling the interrupts on the ADSP-21161N
> 
> My program is completely in C. I set the interrupts using the
> interrupt() function. I tried the "non self-modifying" version of the
> interrupt() function, and also the "fast" and "super fast" vesions,
> niether one seems to help.
> 
> I activate the lower priority Timer interrupt, and interrupt nesting is
> on too.
> 
> What can be wrong? How to solve it?
> Thank you for your time and help.
> 
> Regards,
> 
> JaaC

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?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

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

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

Jaime Andr�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.
�����������������������������������������������������������������������

> Jaime Andr�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

Jerry Avins wrote:
> Jaime Andr�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.

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

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

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