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
|