ISR falls off cliff...sometimes.

I have defined an ISR that responds to an interrupt on the PCI bus from a
host. The current code for this ISR is this:

interrupt void DMAtoHost(void)
{
unsigned int intval,*datastatusregister;
puts("interrupted\n");
datastatusregister = (unsigned int *)DATASTATUSREGISTER;
intval = *datastatusregister & 0x04;
if(intval == 4) { /* is this a host interrupt */
intval = *datastatusregister;
intval = intval & 0xfffffffb;
*datastatusregister = intval; /* if so clear it */
SEM_post(HostDMASem);
puts("resetting PCIIS\n");
}
PCI_RSET(PCIIS,0x00000008);
}

Now, DATASTATUSREGISTER is a memory location on the DSP SDRAM that I have
taken over for tracking status information between my Linux driver and my DSP
interface. Here I am testing a flag in that register to make sure that this
interrupt really was set by the host (my linux driver both sets the interrupt
and sets this flag to tell that it did it), and if so, I clear that location
as well as clearing the PCIIS register.

Basically, if this really was an interrupt from the host, this ISR posts to a
semaphore called HostDMASem, and there is a task sleeping on this semaphore
waiting to be told to transfer data.

I have defined this ISR statically using the Code Composer configuration tool,
and it is hooked to interrupt 13.

I have tried various ways to set that semaphore; my current iteration has the
semaphore defined statically using the configuration tool, and it is
initialized as one of the very first things done in the main routine of the
program when it starts, like this:

SEM_new(HostDMASem,0);

That main task then spawns a new task called buildall_tsk, which is the task
which winds up sleeping on the semaphore. This task arrives at the semaphore
through a subroutine call, like this:

void WaitForDMA(void)
{
Bool semstatus;
SEM_reset(HostDMASem,0);
semstatus = SEM_pend(HostDMASem,SYS_FOREVER);
if(!semstatus){puts("semaphore bombed\n");} else {puts("semaphore
worked\n");}
}

My problem is this. When an interrupt from the host is set, this ISR invokes
apparently correctly. However, sometimes when it reaches the end, it falls
off the cliff (apparently the semaphore is not being recognized properly or
some such) and nothing happens.

Further, when the routine falls off the cliff, subsequent interrupts are
apparently ignored; when the routine falls off the cliff, it doesn't get
invoked again until I completely reset the system (which sometimes involves
cycling power as well as restarting Code Composer.

This seems to be erratic and I can't define specific conditions that cause it
or not. I suspecte some initialization thing that Code Composer is doing,
but I have no idea what.

The card is a Spectrum Digital 6416 card.

I am tearing my hair out over this, and trust me; I don't look good bald.
Anyone here have any idea what is going on? Start a New Thread

I fully expect the stdio things to be dog slow. Right now I don't care. What
I care about is getting this thing to function reliably and consistently.
When I have achieved that, I'll make it go faster - and the various puts will
be the first things removed. At this time, having them there is simply
convenient for me.

The only time I care about stdio right now is if it is the stdio that is
messing up my interrupts/semaphores. Given the nature of things I cannot
rule that out, but I have tested for it and it doesn't seem to be the case.

I think there is some problem/inconsistency about how the executive works with
a mixture of static and dynamic objects, though I am not sure of that either
at this time. I keep playing with it; I am sooooo close to having this whole
thing running...

Once I have the PCI interface fully functional, then I work on the serial
interface. Once I have it done, then I start doing some actual signal
processing in the DSP.

On Monday 22 October 2007 21:46:22 you wrote:
> Hello Jim,
>
> I haven't had time to look at the details of your post, but one thing jumps
> out.
> Do not use any stdio in your ISR [that is my personal rule]. Any stdio is
> v-e-r-y s-l-o-w in 'cpu time'.
> Stdio occurs as the result of a conspiracy between CCS and the compiler.
> The compiler puts a magic label in the stdio code [something like $$CIO$$].
> When you load the program, CCS sets a breakpoint at the label. When you
> run your program, CCS polls the target to see if it is halted. If it is
> halted at the CIO address, CCS will perform a memory read to get the stdio
> 'opcode'. For the puts, he will fetch a string from a buffer located at
> another magical label, the string will be displayed and the target will be
> given a 'run' command. The illusion to the user is similar to what you
> would get on a target with a local console, but it is orderS of magnitude
> slower. If your target is not doing anything useful [processing any other
> interrupts, etc], you might get it to work if the host initiates the
> interrupt every few seconds.
>
> mikedunn
>
> On 10/22/07, jim wrote:
> > I have defined an ISR that responds to an interrupt on the PCI bus from
> > a
> > host. The current code for this ISR is this:
> >
> > interrupt void DMAtoHost(void)
> > {
> > unsigned int intval,*datastatusregister;
> > puts("interrupted\n");
> > datastatusregister = (unsigned int *)DATASTATUSREGISTER;
> > intval = *datastatusregister & 0x04;
> > if(intval == 4) { /* is this a host interrupt */
> > intval = *datastatusregister;
> > intval = intval & 0xfffffffb;
> > *datastatusregister = intval; /* if so clear it */
> > SEM_post(HostDMASem);
> > puts("resetting PCIIS\n");
> > }
> > PCI_RSET(PCIIS,0x00000008);
> > }
> >
> > Now, DATASTATUSREGISTER is a memory location on the DSP SDRAM that I have
> > taken over for tracking status information between my Linux driver and my
> > DSP
> > interface. Here I am testing a flag in that register to make sure that
> > this
> > interrupt really was set by the host (my linux driver both sets the
> > interrupt
> > and sets this flag to tell that it did it), and if so, I clear that
> > location
> > as well as clearing the PCIIS register.
> >
> > Basically, if this really was an interrupt from the host, this ISR posts
> > to a
> > semaphore called HostDMASem, and there is a task sleeping on this
> > semaphore
> > waiting to be told to transfer data.
> >
> > I have defined this ISR statically using the Code Composer configuration
> > tool,
> > and it is hooked to interrupt 13.
> >
> > I have tried various ways to set that semaphore; my current iteration has
> > the
> > semaphore defined statically using the configuration tool, and it is
> > initialized as one of the very first things done in the main routine of
> > the
> > program when it starts, like this:
> >
> > SEM_new(HostDMASem,0);
> >
> > That main task then spawns a new task called buildall_tsk, which is the
> > task
> > which winds up sleeping on the semaphore. This task arrives at the
> > semaphore
> > through a subroutine call, like this:
> >
> > void WaitForDMA(void)
> > {
> > Bool semstatus;
> > SEM_reset(HostDMASem,0);
> > semstatus = SEM_pend(HostDMASem,SYS_FOREVER);
> > if(!semstatus){puts("semaphore bombed\n");} else {puts("semaphore
> > worked\n");}
> > }
> >
> > My problem is this. When an interrupt from the host is set, this ISR
> > invokes
> > apparently correctly. However, sometimes when it reaches the end, it
> > falls
> >
> > off the cliff (apparently the semaphore is not being recognized properly
> > or
> > some such) and nothing happens.
> >
> > Further, when the routine falls off the cliff, subsequent interrupts are
> > apparently ignored; when the routine falls off the cliff, it doesn't get
> > invoked again until I completely reset the system (which sometimes
> > involves
> > cycling power as well as restarting Code Composer.
> >
> > This seems to be erratic and I can't define specific conditions that
> > cause it
> > or not. I suspecte some initialization thing that Code Composer is doing,
> > but I have no idea what.
> >
> > The card is a Spectrum Digital 6416 card.
> >
> > I am tearing my hair out over this, and trust me; I don't look good bald.
> > Anyone here have any idea what is going on?
> > Start a New Thread

Hello Jim,

I haven't had time to look at the details of your post, but one thing jumps
out.
Do not use any stdio in your ISR [that is my personal rule]. Any stdio is
v-e-r-y s-l-o-w in 'cpu time'.
Stdio occurs as the result of a conspiracy between CCS and the compiler.
The compiler puts a magic label in the stdio code [something like $$CIO$$].
When you load the program, CCS sets a breakpoint at the label. When you run
your program, CCS polls the target to see if it is halted. If it is halted
at the CIO address, CCS will perform a memory read to get the stdio
'opcode'. For the puts, he will fetch a string from a buffer located at
another magical label, the string will be displayed and the target will be
given a 'run' command. The illusion to the user is similar to what you
would get on a target with a local console, but it is orderS of magnitude
slower. If your target is not doing anything useful [processing any other
interrupts, etc], you might get it to work if the host initiates the
interrupt every few seconds.

mikedunn

On 10/22/07, jim wrote:
>
> I have defined an ISR that responds to an interrupt on the PCI bus from
> a
> host. The current code for this ISR is this:
>
> interrupt void DMAtoHost(void)
> {
> unsigned int intval,*datastatusregister;
> puts("interrupted\n");
> datastatusregister = (unsigned int *)DATASTATUSREGISTER;
> intval = *datastatusregister & 0x04;
> if(intval == 4) { /* is this a host interrupt */
> intval = *datastatusregister;
> intval = intval & 0xfffffffb;
> *datastatusregister = intval; /* if so clear it */
> SEM_post(HostDMASem);
> puts("resetting PCIIS\n");
> }
> PCI_RSET(PCIIS,0x00000008);
> }
>
> Now, DATASTATUSREGISTER is a memory location on the DSP SDRAM that I have
> taken over for tracking status information between my Linux driver and my
> DSP
> interface. Here I am testing a flag in that register to make sure that
> this
> interrupt really was set by the host (my linux driver both sets the
> interrupt
> and sets this flag to tell that it did it), and if so, I clear that
> location
> as well as clearing the PCIIS register.
>
> Basically, if this really was an interrupt from the host, this ISR posts
> to a
> semaphore called HostDMASem, and there is a task sleeping on this
> semaphore
> waiting to be told to transfer data.
>
> I have defined this ISR statically using the Code Composer configuration
> tool,
> and it is hooked to interrupt 13.
>
> I have tried various ways to set that semaphore; my current iteration has
> the
> semaphore defined statically using the configuration tool, and it is
> initialized as one of the very first things done in the main routine of
> the
> program when it starts, like this:
>
> SEM_new(HostDMASem,0);
>
> That main task then spawns a new task called buildall_tsk, which is the
> task
> which winds up sleeping on the semaphore. This task arrives at the
> semaphore
> through a subroutine call, like this:
>
> void WaitForDMA(void)
> {
> Bool semstatus;
> SEM_reset(HostDMASem,0);
> semstatus = SEM_pend(HostDMASem,SYS_FOREVER);
> if(!semstatus){puts("semaphore bombed\n");} else {puts("semaphore
> worked\n");}
> }
>
> My problem is this. When an interrupt from the host is set, this ISR
> invokes
> apparently correctly. However, sometimes when it reaches the end, it falls
>
> off the cliff (apparently the semaphore is not being recognized properly
> or
> some such) and nothing happens.
>
> Further, when the routine falls off the cliff, subsequent interrupts are
> apparently ignored; when the routine falls off the cliff, it doesn't get
> invoked again until I completely reset the system (which sometimes
> involves
> cycling power as well as restarting Code Composer.
>
> This seems to be erratic and I can't define specific conditions that cause
> it
> or not. I suspecte some initialization thing that Code Composer is doing,
> but I have no idea what.
>
> The card is a Spectrum Digital 6416 card.
>
> I am tearing my hair out over this, and trust me; I don't look good bald.
> Anyone here have any idea what is going on?
>
> Start a New Thread

Jim-

> I fully expect the stdio things to be dog slow. Right now I don't care. What
> I care about is getting this thing to function reliably and consistently.
> When I have achieved that, I'll make it go faster - and the various puts will
> be the first things removed. At this time, having them there is simply
> convenient for me.

What Mike has pointed out means there should be no console I/O (or file I/O) in your
ISR -- at all. If you put those in the ISR, you are the victim of the CCS version of
"Heisenberg Uncertainty Principle" -- i.e. you can no longer measure what's really
happening.

So it's not a question of 'slow', it's a question of 'undefined results'.

Note also that even the "CCS polling" mentioned by Mike tends to slow down executing
code. If you need console or file output and your code is timing sensitive to
real-time events, some alternative ways include:

-acquire data somewhere in DSP mem and display it later

-use HPI or other I/O interface to acquire data while
code is running

-Jeff

> The only time I care about stdio right now is if it is the stdio that is
> messing up my interrupts/semaphores. Given the nature of things I cannot
> rule that out, but I have tested for it and it doesn't seem to be the case.
>
> I think there is some problem/inconsistency about how the executive works with
> a mixture of static and dynamic objects, though I am not sure of that either
> at this time. I keep playing with it; I am sooooo close to having this whole
> thing running...
>
> Once I have the PCI interface fully functional, then I work on the serial
> interface. Once I have it done, then I start doing some actual signal
> processing in the DSP.
>
> On Monday 22 October 2007 21:46:22 you wrote:
> > Hello Jim,
> >
> > I haven't had time to look at the details of your post, but one thing jumps
> > out.
> > Do not use any stdio in your ISR [that is my personal rule]. Any stdio is
> > v-e-r-y s-l-o-w in 'cpu time'.
> > Stdio occurs as the result of a conspiracy between CCS and the compiler.
> > The compiler puts a magic label in the stdio code [something like $$CIO$$].
> > When you load the program, CCS sets a breakpoint at the label. When you
> > run your program, CCS polls the target to see if it is halted. If it is
> > halted at the CIO address, CCS will perform a memory read to get the stdio
> > 'opcode'. For the puts, he will fetch a string from a buffer located at
> > another magical label, the string will be displayed and the target will be
> > given a 'run' command. The illusion to the user is similar to what you
> > would get on a target with a local console, but it is orderS of magnitude
> > slower. If your target is not doing anything useful [processing any other
> > interrupts, etc], you might get it to work if the host initiates the
> > interrupt every few seconds.
> >
> > mikedunn
> >
> > On 10/22/07, jim wrote:
> > > I have defined an ISR that responds to an interrupt on the PCI bus from
> > > a
> > > host. The current code for this ISR is this:
> > >
> > > interrupt void DMAtoHost(void)
> > > {
> > > unsigned int intval,*datastatusregister;
> > > puts("interrupted\n");
> > > datastatusregister = (unsigned int *)DATASTATUSREGISTER;
> > > intval = *datastatusregister & 0x04;
> > > if(intval == 4) { /* is this a host interrupt */
> > > intval = *datastatusregister;
> > > intval = intval & 0xfffffffb;
> > > *datastatusregister = intval; /* if so clear it */
> > > SEM_post(HostDMASem);
> > > puts("resetting PCIIS\n");
> > > }
> > > PCI_RSET(PCIIS,0x00000008);
> > > }
> > >
> > > Now, DATASTATUSREGISTER is a memory location on the DSP SDRAM that I have
> > > taken over for tracking status information between my Linux driver and my
> > > DSP
> > > interface. Here I am testing a flag in that register to make sure that
> > > this
> > > interrupt really was set by the host (my linux driver both sets the
> > > interrupt
> > > and sets this flag to tell that it did it), and if so, I clear that
> > > location
> > > as well as clearing the PCIIS register.
> > >
> > > Basically, if this really was an interrupt from the host, this ISR posts
> > > to a
> > > semaphore called HostDMASem, and there is a task sleeping on this
> > > semaphore
> > > waiting to be told to transfer data.
> > >
> > > I have defined this ISR statically using the Code Composer configuration
> > > tool,
> > > and it is hooked to interrupt 13.
> > >
> > > I have tried various ways to set that semaphore; my current iteration has
> > > the
> > > semaphore defined statically using the configuration tool, and it is
> > > initialized as one of the very first things done in the main routine of
> > > the
> > > program when it starts, like this:
> > >
> > > SEM_new(HostDMASem,0);
> > >
> > > That main task then spawns a new task called buildall_tsk, which is the
> > > task
> > > which winds up sleeping on the semaphore. This task arrives at the
> > > semaphore
> > > through a subroutine call, like this:
> > >
> > > void WaitForDMA(void)
> > > {
> > > Bool semstatus;
> > > SEM_reset(HostDMASem,0);
> > > semstatus = SEM_pend(HostDMASem,SYS_FOREVER);
> > > if(!semstatus){puts("semaphore bombed\n");} else {puts("semaphore
> > > worked\n");}
> > > }
> > >
> > > My problem is this. When an interrupt from the host is set, this ISR
> > > invokes
> > > apparently correctly. However, sometimes when it reaches the end, it
> > > falls
> > >
> > > off the cliff (apparently the semaphore is not being recognized properly
> > > or
> > > some such) and nothing happens.
> > >
> > > Further, when the routine falls off the cliff, subsequent interrupts are
> > > apparently ignored; when the routine falls off the cliff, it doesn't get
> > > invoked again until I completely reset the system (which sometimes
> > > involves
> > > cycling power as well as restarting Code Composer.
> > >
> > > This seems to be erratic and I can't define specific conditions that
> > > cause it
> > > or not. I suspecte some initialization thing that Code Composer is doing,
> > > but I have no idea what.
> > >
> > > The card is a Spectrum Digital 6416 card.
> > >
> > > I am tearing my hair out over this, and trust me; I don't look good bald.
> > > Anyone here have any idea what is going on? Start a New Thread

Hi Jim,

Please look at the page 77 of SPRU581C.pdf, on the bit 4 INTRST of RSTSRC.
It says that "This bit must be asserted before another host interrupt can
be generated."

Next, it would help to parse all the bits in the PCIIS (even if they are
all disabled in the PCIIEN) and clear them in the PCI ISR.

Third, it is recommended to parse an interrupt source register (any of them,
not only the PCIIS) in a loop inside an ISR and clear any set bits until the
register becomes zero, e.g. for the PCI:

volatile uint32 temp;

while (temp = PCIIS) // this reads the PCIIS
{
test if bit[0], ..., [n] is set
if set, clear bit[0], ... [n] and perform the necessary actions, e.g:
if bit[3] HOSTSW was set then clear bit[4] INTRST in RSTSRC
}

// PCIIS is clear now, exit the ISR

Hope this helps,

Andrew

> 11a. ISR falls off cliff...sometimes.
> Posted by: "jim" j...@justsosoftware.com jiml8
> Date: Mon Oct 22, 2007 8:42 pm ((PDT))
>
> I have defined an ISR that responds to an interrupt on the PCI bus from a
> host. The current code for this ISR is this:
>
> interrupt void DMAtoHost(void)
> {
> unsigned int intval,*datastatusregister;
> puts("interrupted\n");
> datastatusregister = (unsigned int *)DATASTATUSREGISTER;
> intval = *datastatusregister & 0x04;
> if(intval == 4) { /* is this a host interrupt */
> intval = *datastatusregister;
> intval = intval & 0xfffffffb;
> *datastatusregister = intval; /* if so clear it */
> SEM_post(HostDMASem);
> puts("resetting PCIIS\n");
> }
> PCI_RSET(PCIIS,0x00000008);
> }
>
> Now, DATASTATUSREGISTER is a memory location on the DSP SDRAM that I have
> taken over for tracking status information between my Linux driver and my DSP
> interface. Here I am testing a flag in that register to make sure that this
> interrupt really was set by the host (my linux driver both sets the interrupt
> and sets this flag to tell that it did it), and if so, I clear that location
> as well as clearing the PCIIS register.
>
> Basically, if this really was an interrupt from the host, this ISR posts to a
> semaphore called HostDMASem, and there is a task sleeping on this semaphore
> waiting to be told to transfer data.
>
> I have defined this ISR statically using the Code Composer configuration tool,
> and it is hooked to interrupt 13.
>
> I have tried various ways to set that semaphore; my current iteration has the
> semaphore defined statically using the configuration tool, and it is
> initialized as one of the very first things done in the main routine of the
> program when it starts, like this:
>
> SEM_new(HostDMASem,0);
>
> That main task then spawns a new task called buildall_tsk, which is the task
> which winds up sleeping on the semaphore. This task arrives at the semaphore
> through a subroutine call, like this:
>
> void WaitForDMA(void)
> {
> Bool semstatus;
> SEM_reset(HostDMASem,0);
> semstatus = SEM_pend(HostDMASem,SYS_FOREVER);
> if(!semstatus){puts("semaphore bombed\n");} else {puts("semaphore
> worked\n");}
> }
>
> My problem is this. When an interrupt from the host is set, this ISR invokes
> apparently correctly. However, sometimes when it reaches the end, it falls
> off the cliff (apparently the semaphore is not being recognized properly or
> some such) and nothing happens.
>
> Further, when the routine falls off the cliff, subsequent interrupts are
> apparently ignored; when the routine falls off the cliff, it doesn't get
> invoked again until I completely reset the system (which sometimes involves
> cycling power as well as restarting Code Composer.
>
> This seems to be erratic and I can't define specific conditions that cause it
> or not. I suspecte some initialization thing that Code Composer is doing,
> but I have no idea what.
>
> The card is a Spectrum Digital 6416 card.
>
> I am tearing my hair out over this, and trust me; I don't look good bald.
> Anyone here have any idea what is going on? Start a New Thread

Well, I did find at least part of my problem.

There seems to be a hardware issue with the memory address/refresh logic.
I've been wrestling with inconsistent behavior, and while I have strongly
suspected hardware, that isn't an easy call to make particularly when
programming at such a low level.

However, I can now document some random changes in program code (which cannot
be accounted for by wild pointers), and using code composer, I watched the
program change a local unsigned int variable (which it was supposed to do),
which also caused the next local unsigned int variable on the same stack to
change as well to the same value (which should be impossible). The variable
that was supposed to be changed was a return from an exec function
(HWI_disable), so if this change is due to some pointer problem, the problem
must be in the HWI_disable function.

This accounts for a lot of things, and I still have some hair left, having not
pulled it all out.

On Tuesday 23 October 2007 11:42:31 you wrote:
> Hi Jim,
>
> Please look at the page 77 of SPRU581C.pdf, on the bit 4 INTRST of RSTSRC.
> It says that "This bit must be asserted before another host interrupt can
> be generated."
>
> Next, it would help to parse all the bits in the PCIIS (even if they are
> all disabled in the PCIIEN) and clear them in the PCI ISR.
>
> Third, it is recommended to parse an interrupt source register (any of
> them, not only the PCIIS) in a loop inside an ISR and clear any set bits
> until the register becomes zero, e.g. for the PCI:
>
> volatile uint32 temp;
>
> while (temp = PCIIS) // this reads the PCIIS
> {
> test if bit[0], ..., [n] is set
> if set, clear bit[0], ... [n] and perform the necessary
> actions, e.g: if bit[3] HOSTSW was set then clear bit[4] INTRST in RSTSRC }
>
> // PCIIS is clear now, exit the ISR
>
> Hope this helps,
>
> Andrew
>
> > 11a. ISR falls off cliff...sometimes.
> > Posted by: "jim" j...@justsosoftware.com jiml8
> > Date: Mon Oct 22, 2007 8:42 pm ((PDT))
> >
> > I have defined an ISR that responds to an interrupt on the PCI bus from a
> > host. The current code for this ISR is this:
> >
> > interrupt void DMAtoHost(void)
> > {
> > unsigned int intval,*datastatusregister;
> > puts("interrupted\n");
> > datastatusregister = (unsigned int *)DATASTATUSREGISTER;
> > intval = *datastatusregister & 0x04;
> > if(intval == 4) { /* is this a host interrupt */
> > intval = *datastatusregister;
> > intval = intval & 0xfffffffb;
> > *datastatusregister = intval; /* if so clear it */
> > SEM_post(HostDMASem);
> > puts("resetting PCIIS\n");
> > }
> > PCI_RSET(PCIIS,0x00000008);
> > }
> >
> > Now, DATASTATUSREGISTER is a memory location on the DSP SDRAM that I have
> > taken over for tracking status information between my Linux driver and my
> > DSP interface. Here I am testing a flag in that register to make sure
> > that this interrupt really was set by the host (my linux driver both sets
> > the interrupt and sets this flag to tell that it did it), and if so, I
> > clear that location as well as clearing the PCIIS register.
> >
> > Basically, if this really was an interrupt from the host, this ISR posts
> > to a semaphore called HostDMASem, and there is a task sleeping on this
> > semaphore waiting to be told to transfer data.
> >
> > I have defined this ISR statically using the Code Composer configuration
> > tool, and it is hooked to interrupt 13.
> >
> > I have tried various ways to set that semaphore; my current iteration has
> > the semaphore defined statically using the configuration tool, and it is
> > initialized as one of the very first things done in the main routine of
> > the program when it starts, like this:
> >
> > SEM_new(HostDMASem,0);
> >
> > That main task then spawns a new task called buildall_tsk, which is the
> > task which winds up sleeping on the semaphore. This task arrives at the
> > semaphore through a subroutine call, like this:
> >
> > void WaitForDMA(void)
> > {
> > Bool semstatus;
> > SEM_reset(HostDMASem,0);
> > semstatus = SEM_pend(HostDMASem,SYS_FOREVER);
> > if(!semstatus){puts("semaphore bombed\n");} else {puts("semaphore
> > worked\n");}
> > }
> >
> > My problem is this. When an interrupt from the host is set, this ISR
> > invokes apparently correctly. However, sometimes when it reaches the
> > end, it falls off the cliff (apparently the semaphore is not being
> > recognized properly or some such) and nothing happens.
> >
> > Further, when the routine falls off the cliff, subsequent interrupts are
> > apparently ignored; when the routine falls off the cliff, it doesn't get
> > invoked again until I completely reset the system (which sometimes
> > involves cycling power as well as restarting Code Composer.
> >
> > This seems to be erratic and I can't define specific conditions that
> > cause it or not. I suspecte some initialization thing that Code Composer
> > is doing, but I have no idea what.
> >
> > The card is a Spectrum Digital 6416 card.
> >
> > I am tearing my hair out over this, and trust me; I don't look good bald.
> > Anyone here have any idea what is going on?
> Start a New Thread

Jim,

On 10/24/07, jim wrote:
> Well, I did find at least part of my problem.
>
> There seems to be a hardware issue with the memory address/refresh logic.
> I've been wrestling with inconsistent behavior, and while I have strongly
> suspected hardware, that isn't an easy call to make particularly when
> programming at such a low level.

Make sure that you go through the EMIF setup parameters, clocks, etc.
to be sure that it is setup correctly. If you used the 'delivered
EMIF settings' and changed any of the clock configuration, your
refresh rate could be too slow.

mikedunn
>
> However, I can now document some random changes in program code (which cannot
> be accounted for by wild pointers), and using code composer, I watched the
> program change a local unsigned int variable (which it was supposed to do),
> which also caused the next local unsigned int variable on the same stack to
> change as well to the same value (which should be impossible). The variable
> that was supposed to be changed was a return from an exec function
> (HWI_disable), so if this change is due to some pointer problem, the problem
> must be in the HWI_disable function.
>
> This accounts for a lot of things, and I still have some hair left, having not
> pulled it all out.
> On Tuesday 23 October 2007 11:42:31 you wrote:
> > Hi Jim,
> >
> > Please look at the page 77 of SPRU581C.pdf, on the bit 4 INTRST of RSTSRC.
> > It says that "This bit must be asserted before another host interrupt can
> > be generated."
> >
> > Next, it would help to parse all the bits in the PCIIS (even if they are
> > all disabled in the PCIIEN) and clear them in the PCI ISR.
> >
> > Third, it is recommended to parse an interrupt source register (any of
> > them, not only the PCIIS) in a loop inside an ISR and clear any set bits
> > until the register becomes zero, e.g. for the PCI:
> >
> > volatile uint32 temp;
> >
> > while (temp = PCIIS) // this reads the PCIIS
> > {
> > test if bit[0], ..., [n] is set
> > if set, clear bit[0], ... [n] and perform the necessary
> > actions, e.g: if bit[3] HOSTSW was set then clear bit[4] INTRST in RSTSRC }
> >
> > // PCIIS is clear now, exit the ISR
> >
> > Hope this helps,
> >
> > Andrew
> >
> > > 11a. ISR falls off cliff...sometimes.
> > > Posted by: "jim" j...@justsosoftware.com jiml8
> > > Date: Mon Oct 22, 2007 8:42 pm ((PDT))
> > >
> > > I have defined an ISR that responds to an interrupt on the PCI bus from a
> > > host. The current code for this ISR is this:
> > >
> > > interrupt void DMAtoHost(void)
> > > {
> > > unsigned int intval,*datastatusregister;
> > > puts("interrupted\n");
> > > datastatusregister = (unsigned int *)DATASTATUSREGISTER;
> > > intval = *datastatusregister & 0x04;
> > > if(intval == 4) { /* is this a host interrupt */
> > > intval = *datastatusregister;
> > > intval = intval & 0xfffffffb;
> > > *datastatusregister = intval; /* if so clear it */
> > > SEM_post(HostDMASem);
> > > puts("resetting PCIIS\n");
> > > }
> > > PCI_RSET(PCIIS,0x00000008);
> > > }
> > >
> > > Now, DATASTATUSREGISTER is a memory location on the DSP SDRAM that I have
> > > taken over for tracking status information between my Linux driver and my
> > > DSP interface. Here I am testing a flag in that register to make sure
> > > that this interrupt really was set by the host (my linux driver both sets
> > > the interrupt and sets this flag to tell that it did it), and if so, I
> > > clear that location as well as clearing the PCIIS register.
> > >
> > > Basically, if this really was an interrupt from the host, this ISR posts
> > > to a semaphore called HostDMASem, and there is a task sleeping on this
> > > semaphore waiting to be told to transfer data.
> > >
> > > I have defined this ISR statically using the Code Composer configuration
> > > tool, and it is hooked to interrupt 13.
> > >
> > > I have tried various ways to set that semaphore; my current iteration has
> > > the semaphore defined statically using the configuration tool, and it is
> > > initialized as one of the very first things done in the main routine of
> > > the program when it starts, like this:
> > >
> > > SEM_new(HostDMASem,0);
> > >
> > > That main task then spawns a new task called buildall_tsk, which is the
> > > task which winds up sleeping on the semaphore. This task arrives at the
> > > semaphore through a subroutine call, like this:
> > >
> > > void WaitForDMA(void)
> > > {
> > > Bool semstatus;
> > > SEM_reset(HostDMASem,0);
> > > semstatus = SEM_pend(HostDMASem,SYS_FOREVER);
> > > if(!semstatus){puts("semaphore bombed\n");} else {puts("semaphore
> > > worked\n");}
> > > }
> > >
> > > My problem is this. When an interrupt from the host is set, this ISR
> > > invokes apparently correctly. However, sometimes when it reaches the
> > > end, it falls off the cliff (apparently the semaphore is not being
> > > recognized properly or some such) and nothing happens.
> > >
> > > Further, when the routine falls off the cliff, subsequent interrupts are
> > > apparently ignored; when the routine falls off the cliff, it doesn't get
> > > invoked again until I completely reset the system (which sometimes
> > > involves cycling power as well as restarting Code Composer.
> > >
> > > This seems to be erratic and I can't define specific conditions that
> > > cause it or not. I suspecte some initialization thing that Code Composer
> > > is doing, but I have no idea what.
> > >
> > > The card is a Spectrum Digital 6416 card.
> > >
> > > I am tearing my hair out over this, and trust me; I don't look good bald.
> > > Anyone here have any idea what is going on?
> >
> >
> >
> >
> > Start a New Thread

On Wednesday 24 October 2007 11:06:48 you wrote:
> Jim,
>
> On 10/24/07, jim wrote:
> > Well, I did find at least part of my problem.
> >
> > There seems to be a hardware issue with the memory address/refresh logic.
> > I've been wrestling with inconsistent behavior, and while I have strongly
> > suspected hardware, that isn't an easy call to make particularly when
> > programming at such a low level.
>
> Make sure that you go through the EMIF setup parameters, clocks, etc.
> to be sure that it is setup correctly. If you used the 'delivered
> EMIF settings' and changed any of the clock configuration, your
> refresh rate could be too slow.
>
> mikedunn
>
I will certainly look at that. I would not have thought it would be possible
to configure the refresh rate from outside. It is certainly not something I
would have ever looked for.

That actually is a possibility???

> > However, I can now document some random changes in program code (which
> > cannot be accounted for by wild pointers), and using code composer, I
> > watched the program change a local unsigned int variable (which it was
> > supposed to do), which also caused the next local unsigned int variable
> > on the same stack to change as well to the same value (which should be
> > impossible). The variable that was supposed to be changed was a return
> > from an exec function (HWI_disable), so if this change is due to some
> > pointer problem, the problem must be in the HWI_disable function.
> >
> > This accounts for a lot of things, and I still have some hair left,
> > having not pulled it all out.
> >
> > On Tuesday 23 October 2007 11:42:31 you wrote:
> > > Hi Jim,
> > >
> > > Please look at the page 77 of SPRU581C.pdf, on the bit 4 INTRST of
> > > RSTSRC. It says that "This bit must be asserted before another host
> > > interrupt can be generated."
> > >
> > > Next, it would help to parse all the bits in the PCIIS (even if they
> > > are all disabled in the PCIIEN) and clear them in the PCI ISR.
> > >
> > > Third, it is recommended to parse an interrupt source register (any of
> > > them, not only the PCIIS) in a loop inside an ISR and clear any set
> > > bits until the register becomes zero, e.g. for the PCI:
> > >
> > > volatile uint32 temp;
> > >
> > > while (temp = PCIIS) // this reads the PCIIS
> > > {
> > > test if bit[0], ..., [n] is set
> > > if set, clear bit[0], ... [n] and perform the necessary
> > > actions, e.g: if bit[3] HOSTSW was set then clear bit[4] INTRST in
> > > RSTSRC }
> > >
> > > // PCIIS is clear now, exit the ISR
> > >
> > > Hope this helps,
> > >
> > > Andrew
> > >
> > > > 11a. ISR falls off cliff...sometimes.
> > > > Posted by: "jim" j...@justsosoftware.com jiml8
> > > > Date: Mon Oct 22, 2007 8:42 pm ((PDT))
> > > >
> > > > I have defined an ISR that responds to an interrupt on the PCI bus
> > > > from a host. The current code for this ISR is this:
> > > >
> > > > interrupt void DMAtoHost(void)
> > > > {
> > > > unsigned int intval,*datastatusregister;
> > > > puts("interrupted\n");
> > > > datastatusregister = (unsigned int *)DATASTATUSREGISTER;
> > > > intval = *datastatusregister & 0x04;
> > > > if(intval == 4) { /* is this a host interrupt */
> > > > intval = *datastatusregister;
> > > > intval = intval & 0xfffffffb;
> > > > *datastatusregister = intval; /* if so clear it */
> > > > SEM_post(HostDMASem);
> > > > puts("resetting PCIIS\n");
> > > > }
> > > > PCI_RSET(PCIIS,0x00000008);
> > > > }
> > > >
> > > > Now, DATASTATUSREGISTER is a memory location on the DSP SDRAM that I
> > > > have taken over for tracking status information between my Linux
> > > > driver and my DSP interface. Here I am testing a flag in that
> > > > register to make sure that this interrupt really was set by the host
> > > > (my linux driver both sets the interrupt and sets this flag to tell
> > > > that it did it), and if so, I clear that location as well as clearing
> > > > the PCIIS register.
> > > >
> > > > Basically, if this really was an interrupt from the host, this ISR
> > > > posts to a semaphore called HostDMASem, and there is a task sleeping
> > > > on this semaphore waiting to be told to transfer data.
> > > >
> > > > I have defined this ISR statically using the Code Composer
> > > > configuration tool, and it is hooked to interrupt 13.
> > > >
> > > > I have tried various ways to set that semaphore; my current iteration
> > > > has the semaphore defined statically using the configuration tool,
> > > > and it is initialized as one of the very first things done in the
> > > > main routine of the program when it starts, like this:
> > > >
> > > > SEM_new(HostDMASem,0);
> > > >
> > > > That main task then spawns a new task called buildall_tsk, which is
> > > > the task which winds up sleeping on the semaphore. This task arrives
> > > > at the semaphore through a subroutine call, like this:
> > > >
> > > > void WaitForDMA(void)
> > > > {
> > > > Bool semstatus;
> > > > SEM_reset(HostDMASem,0);
> > > > semstatus = SEM_pend(HostDMASem,SYS_FOREVER);
> > > > if(!semstatus){puts("semaphore bombed\n");} else {puts("semaphore
> > > > worked\n");}
> > > > }
> > > >
> > > > My problem is this. When an interrupt from the host is set, this ISR
> > > > invokes apparently correctly. However, sometimes when it reaches the
> > > > end, it falls off the cliff (apparently the semaphore is not being
> > > > recognized properly or some such) and nothing happens.
> > > >
> > > > Further, when the routine falls off the cliff, subsequent interrupts
> > > > are apparently ignored; when the routine falls off the cliff, it
> > > > doesn't get invoked again until I completely reset the system (which
> > > > sometimes involves cycling power as well as restarting Code Composer.
> > > >
> > > > This seems to be erratic and I can't define specific conditions that
> > > > cause it or not. I suspecte some initialization thing that Code
> > > > Composer is doing, but I have no idea what.
> > > >
> > > > The card is a Spectrum Digital 6416 card.
> > > >
> > > > I am tearing my hair out over this, and trust me; I don't look good
> > > > bald. Anyone here have any idea what is going on?
> > >
> > >
> >
> > Start a New Thread

I do wish my email client would automatically reply to the group rather than
the person who posted to the group; I keep forgetting to change the "To:"
address when I send these things out...

I'm using Kmail in Linux, BTW.

On Wednesday 24 October 2007 12:08:22 you wrote:
> Jim,
>
> On 10/24/07, jim wrote:
> > On Wednesday 24 October 2007 11:06:48 you wrote:
> > > Jim,
> > >
> > > On 10/24/07, jim wrote:
> > > > Well, I did find at least part of my problem.
> > > >
> > > > There seems to be a hardware issue with the memory address/refresh
> > > > logic. I've been wrestling with inconsistent behavior, and while I
> > > > have strongly suspected hardware, that isn't an easy call to make
> > > > particularly when programming at such a low level.
> > >
> > > Make sure that you go through the EMIF setup parameters, clocks, etc.
> > > to be sure that it is setup correctly. If you used the 'delivered
> > > EMIF settings' and changed any of the clock configuration, your
> > > refresh rate could be too slow.
> > >
> > > mikedunn
> >
> > I will certainly look at that. I would not have thought it would be
> > possible to configure the refresh rate from outside. It is certainly not
> > something I would have ever looked for.
>
> I am not sure what you mean by "from outside" [from outside the RAM??].
> Hopefully your [or someone's] low level initialization code is taking
> care of the EMIF setup. Are you using DSP/BIOS?? or some other
> executive??
>
>From outside the system. I would expect memory refresh rates to be set in the
system and not adjustable from outside. Of course, if the refresh is clocked
from a master clock that can be adjusted from outside, then I suppose this
could be an unintended consequence.

Actually, the symptoms are not fully consistent with refresh problems; a too
slow refresh could account for the mystery changes to memory locations, but
won't account for two local unsigned ints being given the same value when
only one of them was being set. An improperly asserted address line, or a
low voltage, could account for that.

I will look into it, though.

Actually, I have done nothing with low level setup; all of this is being
handled by whatever defaults are provided with Code Composer 3.1. I am using
DSP/BIOS. I don't know how to set up EMIF, but I guess it is time to learn.

> > That actually is a possibility???
>
> Yes, and I have the "have I lost my mind??" experience and the gray
> hair to prove it. I abstain from pulling my hair out :-)
>
> > > > However, I can now document some random changes in program code
> > > > (which cannot be accounted for by wild pointers), and using code
> > > > composer, I watched the program change a local unsigned int variable
> > > > (which it was supposed to do), which also caused the next local
> > > > unsigned int variable on the same stack to change as well to the same
> > > > value (which should be impossible). The variable that was supposed to
> > > > be changed was a return from an exec function (HWI_disable), so if
> > > > this change is due to some pointer problem, the problem must be in
> > > > the HWI_disable function.
> > > >
> > > > This accounts for a lot of things, and I still have some hair left,
> > > > having not pulled it all out.
> > > >
> > > > On Tuesday 23 October 2007 11:42:31 you wrote:
> > > > > Hi Jim,
> > > > >
> > > > > Please look at the page 77 of SPRU581C.pdf, on the bit 4 INTRST of
> > > > > RSTSRC. It says that "This bit must be asserted before another host
> > > > > interrupt can be generated."
> > > > >
> > > > > Next, it would help to parse all the bits in the PCIIS (even if
> > > > > they are all disabled in the PCIIEN) and clear them in the PCI ISR.
> > > > >
> > > > > Third, it is recommended to parse an interrupt source register (any
> > > > > of them, not only the PCIIS) in a loop inside an ISR and clear any
> > > > > set bits until the register becomes zero, e.g. for the PCI:
> > > > >
> > > > > volatile uint32 temp;
> > > > >
> > > > > while (temp = PCIIS) // this reads the PCIIS
> > > > > {
> > > > > test if bit[0], ..., [n] is set
> > > > > if set, clear bit[0], ... [n] and perform the necessary
> > > > > actions, e.g: if bit[3] HOSTSW was set then clear bit[4] INTRST in
> > > > > RSTSRC }
> > > > >
> > > > > // PCIIS is clear now, exit the ISR
> > > > >
> > > > > Hope this helps,
> > > > >
> > > > > Andrew
> > > > >
> > > > > > 11a. ISR falls off cliff...sometimes.
> > > > > > Posted by: "jim" j...@justsosoftware.com jiml8
> > > > > > Date: Mon Oct 22, 2007 8:42 pm ((PDT))
> > > > > >
> > > > > > I have defined an ISR that responds to an interrupt on the PCI
> > > > > > bus from a host. The current code for this ISR is this:
> > > > > >
> > > > > > interrupt void DMAtoHost(void)
> > > > > > {
> > > > > > unsigned int intval,*datastatusregister;
> > > > > > puts("interrupted\n");
> > > > > > datastatusregister = (unsigned int *)DATASTATUSREGISTER;
> > > > > > intval = *datastatusregister & 0x04;
> > > > > > if(intval == 4) { /* is this a host interrupt */
> > > > > > intval = *datastatusregister;
> > > > > > intval = intval & 0xfffffffb;
> > > > > > *datastatusregister = intval; /* if so clear it */
> > > > > > SEM_post(HostDMASem);
> > > > > > puts("resetting PCIIS\n");
> > > > > > }
> > > > > > PCI_RSET(PCIIS,0x00000008);
> > > > > > }
> > > > > >
> > > > > > Now, DATASTATUSREGISTER is a memory location on the DSP SDRAM
> > > > > > that I have taken over for tracking status information between my
> > > > > > Linux driver and my DSP interface. Here I am testing a flag in
> > > > > > that register to make sure that this interrupt really was set by
> > > > > > the host (my linux driver both sets the interrupt and sets this
> > > > > > flag to tell that it did it), and if so, I clear that location as
> > > > > > well as clearing the PCIIS register.
> > > > > >
> > > > > > Basically, if this really was an interrupt from the host, this
> > > > > > ISR posts to a semaphore called HostDMASem, and there is a task
> > > > > > sleeping on this semaphore waiting to be told to transfer data.
> > > > > >
> > > > > > I have defined this ISR statically using the Code Composer
> > > > > > configuration tool, and it is hooked to interrupt 13.
> > > > > >
> > > > > > I have tried various ways to set that semaphore; my current
> > > > > > iteration has the semaphore defined statically using the
> > > > > > configuration tool, and it is initialized as one of the very
> > > > > > first things done in the main routine of the program when it
> > > > > > starts, like this:
> > > > > >
> > > > > > SEM_new(HostDMASem,0);
> > > > > >
> > > > > > That main task then spawns a new task called buildall_tsk, which
> > > > > > is the task which winds up sleeping on the semaphore. This task
> > > > > > arrives at the semaphore through a subroutine call, like this:
> > > > > >
> > > > > > void WaitForDMA(void)
> > > > > > {
> > > > > > Bool semstatus;
> > > > > > SEM_reset(HostDMASem,0);
> > > > > > semstatus = SEM_pend(HostDMASem,SYS_FOREVER);
> > > > > > if(!semstatus){puts("semaphore bombed\n");} else {puts("semaphore
> > > > > > worked\n");}
> > > > > > }
> > > > > >
> > > > > > My problem is this. When an interrupt from the host is set, this
> > > > > > ISR invokes apparently correctly. However, sometimes when it
> > > > > > reaches the end, it falls off the cliff (apparently the semaphore
> > > > > > is not being recognized properly or some such) and nothing
> > > > > > happens.
> > > > > >
> > > > > > Further, when the routine falls off the cliff, subsequent
> > > > > > interrupts are apparently ignored; when the routine falls off the
> > > > > > cliff, it doesn't get invoked again until I completely reset the
> > > > > > system (which sometimes involves cycling power as well as
> > > > > > restarting Code Composer.
> > > > > >
> > > > > > This seems to be erratic and I can't define specific conditions
> > > > > > that cause it or not. I suspecte some initialization thing that
> > > > > > Code Composer is doing, but I have no idea what.
> > > > > >
> > > > > > The card is a Spectrum Digital 6416 card.
> > > > > >
> > > > > > I am tearing my hair out over this, and trust me; I don't look
> > > > > > good bald. Anyone here have any idea what is going on?
> > > > >
> > > > >
> > > >
> > > >
> > > > Messages in this topic (0) Reply (via web post) | Start a new topic
> > > > Messages
> > > > Start a New Thread

On Wednesday 24 October 2007 12:47:47 you wrote:
> Jim-
>
> > Well, I did find at least part of my problem.
> >
> > There seems to be a hardware issue with the memory address/refresh logic.
> > I've been wrestling with inconsistent behavior, and while I have strongly
> > suspected hardware, that isn't an easy call to make particularly when
> > programming at such a low level.
> >
> > However, I can now document some random changes in program code (which
> > cannot be accounted for by wild pointers), and using code composer, I
> > watched the program change a local unsigned int variable (which it was
> > supposed to do), which also caused the next local unsigned int variable
> > on the same stack to change as well to the same value (which should be
> > impossible). The variable that was supposed to be changed was a return
> > from an exec function (HWI_disable), so if this change is due to some
> > pointer problem, the problem must be in the HWI_disable function.
> >
> > This accounts for a lot of things, and I still have some hair left,
> > having not pulled it all out.
>
> Random changes in program code? If this were really happening, it would be
> extremely bad. It would not be worth it to work on any other area of the
> project until this is resolved. My suggestion is to run small, simple code
> that uses only internal mem and try to track down a case of this.
>
> -Jeff
>
I told my client a couple of weeks ago that there were some memory problems.
He took the system and couldn't duplicate the problem I described. I took
the system back and also couldn't repeat the problem. Given that the current
state of our system is "breadboard", I was willing for awhile to write it off
to "one of those things" that happens when you have unboxed hardware and
wires trailing all over the place.

However, I immediately suspected the hardware when some of the things I
encountered over the last few days cropped up, and I have been progressively
simplifying my test case since then, until I did indeed confirm the problem
early this morning.

It's happening, all right.

He purchased a new card, and it is sitting in the box. Needs a bit of wiring
done on the PCI interface to get it to work with our host computer, but
that'll be ready by tomorrow morning. In the meanwhile, I can do a bit of
work on the Linux side of the system.

> > On Tuesday 23 October 2007 11:42:31 you wrote:
> > > Hi Jim,
> > >
> > > Please look at the page 77 of SPRU581C.pdf, on the bit 4 INTRST of
> > > RSTSRC. It says that "This bit must be asserted before another host
> > > interrupt can be generated."
> > >
> > > Next, it would help to parse all the bits in the PCIIS (even if they
> > > are all disabled in the PCIIEN) and clear them in the PCI ISR.
> > >
> > > Third, it is recommended to parse an interrupt source register (any of
> > > them, not only the PCIIS) in a loop inside an ISR and clear any set
> > > bits until the register becomes zero, e.g. for the PCI:
> > >
> > > volatile uint32 temp;
> > >
> > > while (temp = PCIIS) // this reads the PCIIS
> > > {
> > > test if bit[0], ..., [n] is set
> > > if set, clear bit[0], ... [n] and perform the necessary
> > > actions, e.g: if bit[3] HOSTSW was set then clear bit[4] INTRST in
> > > RSTSRC }
> > >
> > > // PCIIS is clear now, exit the ISR
> > >
> > > Hope this helps,
> > >
> > > Andrew
> > >
> > > > 11a. ISR falls off cliff...sometimes.
> > > > Posted by: "jim" j...@justsosoftware.com jiml8
> > > > Date: Mon Oct 22, 2007 8:42 pm ((PDT))
> > > >
> > > > I have defined an ISR that responds to an interrupt on the PCI bus
> > > > from a host. The current code for this ISR is this:
> > > >
> > > > interrupt void DMAtoHost(void)
> > > > {
> > > > unsigned int intval,*datastatusregister;
> > > > puts("interrupted\n");
> > > > datastatusregister = (unsigned int *)DATASTATUSREGISTER;
> > > > intval = *datastatusregister & 0x04;
> > > > if(intval == 4) { /* is this a host interrupt */
> > > > intval = *datastatusregister;
> > > > intval = intval & 0xfffffffb;
> > > > *datastatusregister = intval; /* if so clear it */
> > > > SEM_post(HostDMASem);
> > > > puts("resetting PCIIS\n");
> > > > }
> > > > PCI_RSET(PCIIS,0x00000008);
> > > > }
> > > >
> > > > Now, DATASTATUSREGISTER is a memory location on the DSP SDRAM that I
> > > > have taken over for tracking status information between my Linux
> > > > driver and my DSP interface. Here I am testing a flag in that
> > > > register to make sure that this interrupt really was set by the host
> > > > (my linux driver both sets the interrupt and sets this flag to tell
> > > > that it did it), and if so, I clear that location as well as clearing
> > > > the PCIIS register.
> > > >
> > > > Basically, if this really was an interrupt from the host, this ISR
> > > > posts to a semaphore called HostDMASem, and there is a task sleeping
> > > > on this semaphore waiting to be told to transfer data.
> > > >
> > > > I have defined this ISR statically using the Code Composer
> > > > configuration tool, and it is hooked to interrupt 13.
> > > >
> > > > I have tried various ways to set that semaphore; my current iteration
> > > > has the semaphore defined statically using the configuration tool,
> > > > and it is initialized as one of the very first things done in the
> > > > main routine of the program when it starts, like this:
> > > >
> > > > SEM_new(HostDMASem,0);
> > > >
> > > > That main task then spawns a new task called buildall_tsk, which is
> > > > the task which winds up sleeping on the semaphore. This task arrives
> > > > at the semaphore through a subroutine call, like this:
> > > >
> > > > void WaitForDMA(void)
> > > > {
> > > > Bool semstatus;
> > > > SEM_reset(HostDMASem,0);
> > > > semstatus = SEM_pend(HostDMASem,SYS_FOREVER);
> > > > if(!semstatus){puts("semaphore bombed\n");} else {puts("semaphore
> > > > worked\n");}
> > > > }
> > > >
> > > > My problem is this. When an interrupt from the host is set, this ISR
> > > > invokes apparently correctly. However, sometimes when it reaches the
> > > > end, it falls off the cliff (apparently the semaphore is not being
> > > > recognized properly or some such) and nothing happens.
> > > >
> > > > Further, when the routine falls off the cliff, subsequent interrupts
> > > > are apparently ignored; when the routine falls off the cliff, it
> > > > doesn't get invoked again until I completely reset the system (which
> > > > sometimes involves cycling power as well as restarting Code Composer.
> > > >
> > > > This seems to be erratic and I can't define specific conditions that
> > > > cause it or not. I suspecte some initialization thing that Code
> > > > Composer is doing, but I have no idea what.
> > > >
> > > > The card is a Spectrum Digital 6416 card.
> > > >
> > > > I am tearing my hair out over this, and trust me; I don't look good
> > > > bald. Anyone here have any idea what is going on? Start a New Thread