Reply by Brian C. Lane June 7, 20042004-06-07
Brian C. Lane wrote:

> Brian C. Lane wrote: >>This code runs in an interrupt (a DMA irq)
>>
>> TC = (*(_timer_10ms) == #0)
>> if(TC) goto hold_10ms
>> *(_timer_10ms) -= #1
> > I can reproduce this every time now.
>
> Make the code look like this:
>
> *(_timer_10ms) = #1
> OVM = 1
> SXM = 0
>
> TC = (*(_timer_10ms) == #0)
> if(TC) goto hold_10ms
> *(_timer_10ms) -= #1
> hold_10ms:
>

TI Bug #SDSsq14655

Brian

--
-----------------
Brian C. Lane (W7BCL) Programmer
www.shinemicro.com RF, DSP & Microcontroller Design


Reply by Brian C. Lane June 4, 20042004-06-04
Brian C. Lane wrote:

> This code runs in an interrupt (a DMA irq)
>
> TC = (*(_timer_10ms) == #0)
> if(TC) goto hold_10ms
> *(_timer_10ms) -= #1
>

I can reproduce this every time now.

Make the code look like this:

*(_timer_10ms) = #1
OVM = 1
SXM = 0

TC = (*(_timer_10ms) == #0)
if(TC) goto hold_10ms
*(_timer_10ms) -= #1
hold_10ms:

Then when it decrements to 0 the !@$*#(R&@& processor sets the target
variable to 0x7FFF!!

Why the %(#&$!(&*#$ blazes does it do this? It didn't roll over, it
decremented to zero!

I also checked to see if values of A had any effect and they don't, at
least that I can tell.

Is this a known bug? I'm searching the knowledge base but not having any
luck.

This is on a C5416 and timer_10ms is at 0x32D3 for whatever that's worth.

Brian

Here's a copy of what I submitted to TI's tech support web form, just
for reference. I'm fairly positive that I've found a real bug in the
'5416 or at least in the part that I have (TMX320VC5416PGE C-OCAF77W) on
the bench right now.

I think I have found a bug in the '5416 ALU operation.

I have a 16 bit unsigned variable at memory location 0x32D3 called
timer_10ms

In an interrupt (and probably in non-interrupt as well) if I execute the
following code (in algebraic syntax):

*(_timer_10ms) = #1
OVM = 1
SXM = 0

TC = (*(_timer_10ms) == #0)
if(TC) goto hold_10ms
*(_timer_10ms) -= #1
hold_10ms:

The target variable gets set to 0x7FFF every time! I don't understand
what happenes because the decrement doesn't underflow, and the 0x7FFF
would indicate that it had overflowed which it also didn't so.

This does not happen for any other combination of SXM and OVM (ie. both
set to 1 you would expect the same behavior but it works correctly and
sets it to 0).

I also tried various settings in the A accumulator to see if they have
any effect, and they don't, at least as far as I can tell.

This is an easy bug to work around, just set SXM and OVM to 0, but it is
a subversive bug, one that is VERY difficult to track down and can cause
a variety of odd behaviors if you don't closely monitor each variable.

Is this a known problem? Am I all wet? Or is this something new?

Thanks,

Brian --
-----------------
Brian C. Lane (W7BCL) Programmer
www.shinemicro.com RF, DSP & Microcontroller Design



Reply by Brian C. Lane June 4, 20042004-06-04

This code runs in an interrupt (a DMA irq)

TC = (*(_timer_10ms) == #0)
if(TC) goto hold_10ms
*(_timer_10ms) -= #1

In non-interrupt time I check for it being at 0, do some stuff, and
reset it to 12.

if( timer_10ms == 0 )
{
inc_clock(); /* Increment the clock */

timer_10ms = 12;
}

Most of the time it works.

Sometimes timer_10ms gets set to 0x7FFF

timer_10ms is an unsigned int, I have even added unused guard words on
either side to detect whether the clobberer is pointing to the variable
or to a constant memory location. timer_10ms still gets set to 0x7FFF
when I move it around memory.

It doesn't get set to 0x7FFF when I comment out the decrement in the
interrupt.

Interrupts are off in the interrupt, so it can't get re-interrupted. and
the decrement (and set in non interrupt code) are single instructions so
they can't get interrupted anyway.

I'm getting close to being stuck on this one. Any ideas? Things to try?
I've tried adding 2 nops on either side of the decrement, with no
obvious improvement.

Nothing else in the code uses this variable, there are no unaligned
doubles nearby in memory :) and the guard words I added never change
from 0x0000 so something isn't writing through memory like crazy.

Thanks,

Brian --
-----------------
Brian C. Lane (W7BCL) Programmer
www.shinemicro.com RF, DSP & Microcontroller Design