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 |
|
Increment Getting Clobbered
Started by ●June 4, 2004
Reply by ●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 ●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 |