• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 855 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

McBSP Missing Interrupts

Brian Sarvis
Prodigy 160 points
Other Parts Discussed in Thread: SYSBIOS

Hello,

I'm new to DSPs, and have been working on getting audio through the McBSP port on a C6424. The target hardware is of our own design, but is loosely based on the C6424EVM. I've been able to do simple polling, and EDMA without the help of Sys/Bios. All of these attempts work very well.

I've now added Sys/Bios to the mix and am trying to create a simple interrupt routine.

The McBSP is a slave in this case, and is receiving clocks for a TDM stream of 10 channels (one phase). I've attached a .pdf of the interrupt service routine, and the Sys/Bios configuration. The code simply puts out samples from a multiplexed sine table.

The routine seems to work, but the channels rotate about once a second, as if an interrupt was being missed.  In the idle task, I’m monitoring the missed interrupt registers, but they’re not showing anything.  If I deliberately miss interrupts (by globally disabling them for a time), my little warning system goes off.  However, if I put a long delay inside the ISR such that it is obviously missing interrupts, I don’t get the same indication.  So, that’s my first quandary. 

I think I've disabled every other hardware interrupt in the system. Enabling hardware interrupt tracking in the Execution graph breaks the code (it seems to run too slowly).

Another interesting tidbit is that if I disable full debugging capabilities, I get hash on the outputs. Yet, I must have full optimization turned on.

Anyway, the big question is, what's holding up the ISR, if anything?

By the way, what are the "priorities" of the interrupts? Is a higher numbered interrupt a higher priority than a lowered numbered interrupt (the same as with SWIs)?

Thanks for the help.

Brian

Sys/Bios 6_33_05_46

XDC 3_23_03_53

CCS Version: 5.2.1.00018

 

Problem Child.pdf
  • 0
    TI__Mastermind 32475 points

    Brian,

    How are you creating your "simple interrupt routine"?  Are you creating this via Hwi module because BIOS requires that you do so.

    If you are doing such a thing do you realize that BIOS re-enables interrupts within an ISR?  So when you say "I put a long delay inside the ISR", most likely its really not disabling interrupts.  There is a way to disable a particular interrupt while processing another interrupt.  You can do this by setting the interrupt mask.

    For interrupts, lower number means higher priority.  So Interrupt 4 has higher priority than interrupt 5 and so on.  The priority only comes into play when both interrupts arrive simultaneously.

    Judah

  • 0 in reply to judahvang
    Prodigy 160 points

    Hello Judah,

    Thanks for your quick response.

    Yes, the HWI is being configured via the Sys/Bios GUI.  I attached a screen shot.

    The HWI is self-masking, though I have tried other options as well - no mask, all mask, etc.

    Brian

  • 0 in reply to Brian Sarvis
    Prodigy 160 points

    It occurs to me to ask three questions with regard to this

    1)  If I disable the clock module in the GUI, are there any other hardware interrupts used by Sys/Bios?

    2)  If an ISR is self-masking, and an event is triggered while the DSP is in the ISR, would this generate a flag in the IDROP register and trigger the INTERR?

    3)  If full debugging is enabled as well as optimization Level 3, what is the interrupt latency of the C6424 and Sys/Bios?

    Thanks.

    Brian

  • 0 in reply to Brian Sarvis
    TI__Mastermind 32475 points

    Brian,

    #1.  If you disable the Clock module there should be no other hardware interrupts used by SYSBIOS

    #2.  If the ISR is self-masking, the interrupt will not be triggered until you exist the ISR.  The masking basically disables the IER so even though the flag is triggered and the IFR bit is set, the ISR will not be taken until the IER (Interrupt enable register) bit is enabled.  If the mask is ALL then no interrupt would be taken.

    #3.  You can look at the c6000 benchmarks included with the installation.  I don't know for sure if full debugging is enabled for the benchmarks but I know it is highly optimized.

    Judah

  • 0 in reply to judahvang
    Prodigy 160 points

    Hi Judah,

    Thanks for sticking with me here.  More experimenting today.

    #1 - Interestingly, I disabled hardware interrupts using Hwi_disable() in an idle task for a second at a time.  I then get interrupt errors saying the timer interrupt was missed (CPU Interrupt 14, Event 4, Timer 0).  So, even though the clock module is disabled, the timer hardware interrupts are not.   The only way around this seems to be to enable the clock module, and set it to something ridiculously long, like 1 second.  I then don't see the interrupt error.  Even more telling is if I disable the clock module, and then try to put something into CPU interrupt slot 14, the XDC verification throws an error, saying there's already an interrupt in that slot.  So, the question here is, how do I get rid of that timer interrupt?

    #2 - If I use Hwi_disableInterrupt(5), which is a McBSP Tx interrupt (Event 50), and disable it for a second at a time, no hardware interrupt error is generated.   This is true even if I set the clock module for a period of 1 second as noted above.   Is this because that function is setting the event mask, so the interrupt module never sees the event?  Ok, so I use INDMASK to mask off the errant clock message I don't want, and then disable all interrupts for long periods of time.  I still don't get an interrupt error.  So, I guess the question becomes, what am I doing wrong, or what good is this interrupt error flag?

    #3 - Thanks!  Found them.

    #4 - New question - in Section 7.5.3.4 of SPRU871K, it says the INTDMASK register is read-only.  So, I'm left wondering what the point of that register is, or if it is just a misprint, and if it is indeed read/write.   Well, that one's easy enough to answer.  I wrote to it, and then read it back.  The non-reserved bits came back correct, so it must be a misprint.

    Thanks again.

    Brian

  • 0 in reply to Brian Sarvis
    TI__Mastermind 32475 points

    Brian,

    #1.  If you add "BIOS.clockEnabled = false;" in your *.cfg script it should disable the Clock module and not create the Timer.

    #2.  Hwi_disableInterrupt(5) will set the IER (Interrupt enable bit) bit 5 to 0.  So the McBSP might flag an event to the interrupt controller but the interrupt won't be taken until the IER bit 5 is enabled.  Now concerning whether the interrupt module gets the interrupt, I think yes it does get it.

    If you get the Timer disabled via #1, It might make sense to move this to a c6000 thread forum so you get more knowledgeable hardware people who could probably answer the INTDMASK question.

    Judah

  • 0 in reply to judahvang
    Prodigy 160 points

    #1 - yes, that did the trick.  I finally found it in the GUI as well.  Under the Sys/Bios basic runtime options, there's an "Enable Clock Manager" checkbox.  If it is checked, the timer interrupt is set up, even if there is not a clock module present. 

    #2 - Masking vs. getting an interrupt error flag.  Still not sure here.  Even when I deliberately hold off interrupts with the Hwi_disable() in the Idle task, I do not get any errors.  So, I'll move that question over to the C6000 thread.

     

    Thanks for all your help.

    Brian