Re: Hardware Interrupts unexpectedly disabled for short periods of time TMS320C6416

Luc,
I agree with Jeff it is most likely a library routine.
If you can tell in your interrupt routine that you were late, check the IRP address. It probably points to an instruction that turned the interrupts back on.
Good luck.
TK

----- Original Message ----
From: Jeff Brower
To: Luc Savard
Cc: c...
Sent: Thursday, August 14, 2008 2:10:30 AM
Subject: Re: [c6x] Hardware Interrupts unexpectedly disabled for short periods of time TMS320C6416
Luc-

> It looks like the hardware interrupts are being disabled for short
> periods of time and I don't understand why. The duration of these
> periods are a few mili-seconds.
>
> I know that the HWI can be disabled during loops if you set the
> opmization level to -o2 or -o3. However, all the files in my
> project have their optimazation levels either set to -o1 or 'None'
> so that is not it.
>
> I looked in the assembly code and it does not mention anything about
> Interrupts being disabled anywhere. The only thing the Headers in
> the .asm files do say is "Interrupt thrhld: Disabled" and I think
> that this is normal since the optimazation levels are really low.
>
> I am familiar with the functions: IRQ_Disable, IRQ_Enable,
> HWI_Disable and HWI_Enable. I inspected the code and they are not
> the cause of this problem. I don't have any self modifying code in
> either my project.
>
> So, what else could be the cause for the HWI to be disabled?
> Are there other events that cause the TMS320C6416 to disable/enable
> interrupts I should be aware of?

What libraries are you linking? You could be calling DSP lib functions that turn
interrupts off inside highly optimized asm code.

A brute-force thing you could do is create a binary image text file using hex6x.exe,
scan that for interrupt disable/enable op-codes, and figure out at which addresses
these occur. Then set breakpoints to discover the culprit code. I always like to
bet young engineers who work for me that something like this actually is in their
code, even though they swear it's not. Haha. Guess who wins.

-Jeff Start a New Thread

You are right it is the FIR filter routine that is disabling the
interrupts. The documentation says it is interrupt tolerant but not
interruptible and now I know what that means.

Thank you for your help guys.

________________________________

From: Tom Kerekes [mailto:t...@yahoo.com]
Sent: Thursday, August 14, 2008 2:15 PM
To: Jeff Brower; Savard, Luc (Contractor)
Cc: c...
Subject: Re: [c6x] Hardware Interrupts unexpectedly disabled for short
periods of time TMS320C6416

Luc,

I agree with Jeff it is most likely a library routine.

If you can tell in your interrupt routine that you were late, check the
IRP address. It probably points to an instruction that turned the
interrupts back on.

Good luck.

TK

----- Original Message ----
From: Jeff Brower
To: Luc Savard
Cc: c...
Sent: Thursday, August 14, 2008 2:10:30 AM
Subject: Re: [c6x] Hardware Interrupts unexpectedly disabled for short
periods of time TMS320C6416

Luc-

> It looks like the hardware interrupts are being disabled for short
> periods of time and I don't understand why. The duration of these
> periods are a few mili-seconds.
>
> I know that the HWI can be disabled during loops if you set the
> opmization level to -o2 or -o3. However, all the files in my
> project have their optimazation levels either set to -o1 or 'None'
> so that is not it.
>
> I looked in the assembly code and it does not mention anything about
> Interrupts being disabled anywhere. The only thing the Headers in
> the .asm files do say is "Interrupt thrhld: Disabled" and I think
> that this is normal since the optimazation levels are really low.
>
> I am familiar with the functions: IRQ_Disable, IRQ_Enable,
> HWI_Disable and HWI_Enable. I inspected the code and they are not
> the cause of this problem. I don't have any self modifying code in
> either my project.
>
> So, what else could be the cause for the HWI to be disabled?
> Are there other events that cause the TMS320C6416 to disable/enable
> interrupts I should be aware of?

What libraries are you linking? You could be calling DSP lib functions
that turn
interrupts off inside highly optimized asm code.

A brute-force thing you could do is create a binary image text file
using hex6x.exe,
scan that for interrupt disable/enable op-codes, and figure out at which
addresses
these occur. Then set breakpoints to discover the culprit code. I always
like to
bet young engineers who work for me that something like this actually is
in their
code, even though they swear it's not. Haha. Guess who wins.

-Jeff Start a New Thread