Reply by October 7, 20052005-10-07
I think you can write the C isr with NMI_INTERRUPT pragma and plug it
in cdb.

~ richard ~


Mark Robinson wrote:
> Hi, > > Is it possible to call a C handler function in response to a NMI > in a c6000 (specifically DM642) DSP/BIOS program? What precautions > do I need to take since I can't use the DSP/BIOS dispatcher? I'm > guessing I need to do a B NRP somewhere, so could I just add > B NRP > NOP 5 > in asm() blocks at the end of my C handler, or is that a no-no? > > Cheers > > mark-r > > -- > "Let's meet the panel. You couldn't ask for four finer comedians - > so that answers your next question..." > -- Humphrey Lyttleton
Reply by Noway2 October 7, 20052005-10-07
I think you have hit on the crux of my problem.  Apparently in my
original(?) code I had a routine call for IRQ_enable.  Apparently,
though, something is missing as the linker complains that it can't find
it.  There seems to be some question at the moment about wether or not
there is a CSL for the c2000 series processor.

At this point, I think I may have to break down and contact TI.

Thank You for your help!

Matt

Reply by Mark Robinson October 7, 20052005-10-07
Noway2 wrote:
> > keypress) It seems to me that if you declare an interrupt the BIOS > should at least enable it. I also don't see any commands to enable or > disable a particular IRQ, just all ints. Any ideas?
IIRC, setting a handler does not enable the interrupt. You have to do that using the IRQ_... functions from the Chip Support Library for your processor. In some test code I'm writing, I have done the following to enable the McBSP0 XINT interrupt: IRQ_map(IRQ_EVT_XINT0, 12); HWI_dispatchPlug(12, (Fxn)McBSP_XInt0, -1, NULL); IRQ_clear(IRQ_EVT_XINT0); IRQ_enable(IRQ_EVT_XINT0); Cheers mark-r -- "Let's meet the panel. You couldn't ask for four finer comedians - so that answers your next question..." -- Humphrey Lyttleton
Reply by Noway2 October 7, 20052005-10-07
You have a good point there about not being able to do anything usefull
if you follow their instructions.  I haven't tried using the NMI yet,
just the interrupts from the external interface.  It sounds to me like
TI anticipates the NMI to be used for something like a power fail int
or some other function that won't do much of anything.  As a thought,
the source code is provided for (most) of the bios and other functions.
 Perhaps you could copy one of the asm routines and modify it slightly
for your purposes.  You could then pass control to a C routine, which
returns to the assembly routine to exit.  This may be a bit on the slow
side if you are concerned about speed.

Speaking interrupts and the BIOS, I had the XINTF interrupt working at
one point, but yesterday I tried to implement it again and ran into
some difficulty.  From what I can tell, the interrupt enable line in
the IER register is being cleared by the BIOS automatically.  The
interrupt I am using is one of the PIE interrupts (PIE1.4 to be exact).
 Even though I register this interrupt in the BIOS by declaring a
handler and setting the dispatcher, the interrupt line does not get
enabled and I consequently, I am not getting interrupts.  I have tried
enabling this line, etc all to no avail.  If I use a non bios
application I can watch the IER and IFR clear and set bit 0 when I
trigger an interrupt (they are generated by an FPGA on a debounced
keypress) It seems to me that if you declare an interrupt the BIOS
should at least enable it.  I also don't see any commands to enable or
disable a particular IRQ, just all ints.  Any ideas?

Reply by Mark Robinson October 7, 20052005-10-07

Noway2 wrote:
> > First, what is there a reason you can't use the dispatcher?
You can't use the dispatcher for NMI. The DSP/BIOS Users Guide says: "Do not call HWI_enter, HWI_exit, or any other DSP/BIOS functions from a non-maskable interrupt (NMI) service routine. In addition, the HWI dispatcher cannot be used with the NMI service routine." and if you try to tick the Use Dispatcher box in the config tool, it complains. If you follow the above rule to the letter, it seems that you can't do anything useful from an NMI! As you say, the normal approach to handling an interrupt is to post a SWI or wake a pending task, but SWI_post and SEM_post are DSP/BIOS functions, and so illegal in an NMI. I can't see any fundamental reason why an NMI can't be treated exactly the same as an IRQ from a handling point of view, but TI seem to think differently. Cheers mark-r -- "Let's meet the panel. You couldn't ask for four finer comedians - so that answers your next question..." -- Humphrey Lyttleton
Reply by Noway2 October 6, 20052005-10-06
I am not familiar with your particular processor, though I have
implemented interrupts in the DSP BIOS of a C2000 series.

First, what is there a reason you can't use the dispatcher?  I believe
that the use of the dispatched allows you to write your interrupts
entirely in C.

If you don't use the dispatcher, you need to write an assembly language
wrapper around your C function that gets called.  You will need to make
sure that the interrupts are handled correctly as far as what happens
if a higher priority interrupts your interrupt and and potential
re-entrancy issues.  You will also need to make sure that your
interrupts get acknowledged properly.

Also with interrupts in the BIOS, I believe that often times the
recommend approach is to schedule a software interrupt to handle all
but the most basic of interrupt tasks.  Perhaps you could write the
simple hardware interrupt in assembly (or copy an example) and then
write your software interrupt in C.

Reply by Mark Robinson October 6, 20052005-10-06
Hi,

Is it possible to call a C handler function in response to a NMI
in a c6000 (specifically DM642) DSP/BIOS program? What precautions
do I need to take since I can't use the DSP/BIOS dispatcher? I'm
guessing I need to do a B NRP somewhere, so could I just add
B    NRP
NOP  5
in asm() blocks at the end of my C handler, or is that a no-no?

Cheers

mark-r

-- 
"Let's meet the panel. You couldn't ask for four finer comedians -
so that answers your next question..."
 -- Humphrey Lyttleton