I'm looking for ideas on how to find a particularly elusive bug. The target is a C5509A using DSP/BIOS, CSL, and DSPlib. I have a task written in C that runs forever. The compiler has used the T3 register to store an array offset. It initializes T3 prior to the main loop in this task, which then cycles indefinately, pending on mailbox and timer events. In this context, T3 should never change, but it is getting corrupted by some other task or function. Fortunately this leads only to incorrect results instead of complete mayhem, but it still needs to be fixed. If I am screwing up T3 myself, it must be because of something I've written in assembly language. I have two time-critical functions written in algebraic assembly. I also have a short HWI function. The HWI looks schematically like this: HWI_enter... AR1 = something XAR0 = address of SWI below SWI_inc HWI_exit.. The first ASM function runs as a SWI posted from the HWI. I strongly suspected this function because it processes ADC values, and T3 is getting overwritten with an address 256 words into my ADC buffer. But in this function, I only set T3 to 0 or 1, which doesn't fit. I've checked the code, and I'm saving T3 on entry and restoring it on exit. Prior to restoring context, I make calls to SWI_inc and SWI_dec. The SWI_dec call posts a C-language routine which ends up calling my second assembly language function, described below. This second ASM function is a special-size FFT. It, too, saves and restores T3. Inside this function, T3 gets used to store the offset of my twiddle table, which isn't the rogue number in question. So if I'm not the one corrupting T3, how can I find out who is? I'd really love to be able to break on a T3 load, but my Spectrum Digital emulators can't do this sort of thing. Anyone got another idea? David L. Rick Hach Company |
T3 reg corrupted; How to find out whodunnit?
Started by ●February 4, 2005
Reply by ●February 4, 20052005-02-04
On Fri, 04 Feb 2005 22:38:55 -0000 "David Rick" <> wrote: > > I'm looking for ideas on how to find a particularly elusive bug. The > target is a C5509A using DSP/BIOS, CSL, and DSPlib. > > I have a task written in C that runs forever. The compiler has used > the T3 register to store an array offset. It initializes T3 prior to > the main loop in this task, which then cycles indefinately, pending > on mailbox and timer events. In this context, T3 should never > change, but it is getting corrupted by some other task or function. > Fortunately this leads only to incorrect results instead of complete > mayhem, but it still needs to be fixed. > > If I am screwing up T3 myself, it must be because of something I've > written in assembly language. I have two time-critical functions > written in algebraic assembly. I also have a short HWI function. > It sounds horrid. I think you're concentrating on code which might do "T3 = something", having failed to save or restore context correctly. Could it not be that a wild write is hitting the memory-mapped location of T3? I would try to disable various bits of the functionality of the system while disturbing the overall operation as little as possible, in the hope of finding a clue: eg replace parts of your signal processing with null operations not involving pointers. Of course, CSL and DSP/BIOS are very capable of having bugs. Tim. ------------------------ Tim Thorpe Tel: +44 1223 240366 Fax: +44 1223 414402 ------------------------ |
Reply by ●February 5, 20052005-02-05
did you saved the context of T3 and restored back in asm files which you coded???? Cheers -Lakshman --- Tim Thorpe <> wrote: > On Fri, 04 Feb 2005 22:38:55 -0000 > "David Rick" <> wrote: > > > > > I'm looking for ideas on how to find a > particularly elusive bug. The > > target is a C5509A using DSP/BIOS, CSL, and > DSPlib. > > > > I have a task written in C that runs forever. The > compiler has used > > the T3 register to store an array offset. It > initializes T3 prior to > > the main loop in this task, which then cycles > indefinately, pending > > on mailbox and timer events. In this context, T3 > should never > > change, but it is getting corrupted by some other > task or function. > > Fortunately this leads only to incorrect results > instead of complete > > mayhem, but it still needs to be fixed. > > > > If I am screwing up T3 myself, it must be because > of something I've > > written in assembly language. I have two > time-critical functions > > written in algebraic assembly. I also have a short > HWI function. > > > > It sounds horrid. > > I think you're concentrating on code which might do > "T3 = something", > having failed to save or restore context correctly. > > Could it not be that a wild write is hitting the > memory-mapped > location of T3? > > I would try to disable various bits of the > functionality of the > system while disturbing the overall operation as > little as possible, > in the hope of finding a clue: eg replace parts of > your signal > processing with null operations not involving > pointers. > > Of course, CSL and DSP/BIOS are very capable of > having bugs. > > Tim. ------------------------ > Tim Thorpe Tel: +44 1223 > 240366 > Fax: +44 > 1223 414402 > ------------------------ > __________________________________________________ |
Reply by ●February 7, 20052005-02-07
hi, May be you can use the breakpoints and single stepping features to find where exactly the T3 gets the unexpected value. Are you passing more number of values to the called function which forces the system to use stack apart from the ususal T and AR registers? It can also be that there is a bug in bios functions or the way your CCS version works. regards, Dileepan. --- David Rick <> wrote: > > > I'm looking for ideas on how to find a particularly > elusive bug. The > target is a C5509A using DSP/BIOS, CSL, and DSPlib. > > I have a task written in C that runs forever. The > compiler has used > the T3 register to store an array offset. It > initializes T3 prior to > the main loop in this task, which then cycles > indefinately, pending > on mailbox and timer events. In this context, T3 > should never > change, but it is getting corrupted by some other > task or function. > Fortunately this leads only to incorrect results > instead of complete > mayhem, but it still needs to be fixed. > > If I am screwing up T3 myself, it must be because of > something I've > written in assembly language. I have two > time-critical functions > written in algebraic assembly. I also have a short > HWI function. > > The HWI looks schematically like this: > HWI_enter... > AR1 = something > XAR0 = address of SWI below > SWI_inc > HWI_exit.. > > The first ASM function runs as a SWI posted from the > HWI. I strongly > suspected this function because it processes ADC > values, and T3 is > getting overwritten with an address 256 words into > my ADC buffer. But > in this function, I only set T3 to 0 or 1, which > doesn't fit. I've > checked the code, and I'm saving T3 on entry and > restoring it on > exit. Prior to restoring context, I make calls to > SWI_inc and > SWI_dec. The SWI_dec call posts a C-language routine > which ends up > calling my second assembly language function, > described below. > > This second ASM function is a special-size FFT. It, > too, saves and > restores T3. Inside this function, T3 gets used to > store the offset > of my twiddle table, which isn't the rogue number in > question. > > So if I'm not the one corrupting T3, how can I find > out who is? I'd > really love to be able to break on a T3 load, but my > Spectrum Digital > emulators can't do this sort of thing. Anyone got > another idea? > > David L. Rick > Hach Company __________________________________________________ |
Reply by ●February 14, 20052005-02-14
--- In , "David Rick" <davidlrick@y...> wrote: Thanks to everyone who replied, including several who sent me private email. It seems that the problem is DSP/BIOS breaking the C calling conventions for save-on-entry registers. I found and fixed the problem by changing my interrupt routine to save more registers before making a BIOS call. The difference is in the first argument passed to HWI_enter and HWI_exit. C55_AR_DR_BIOS_CONTEXT_MASK (defined in C55.h55) should save the ARn and Tn regs that BIOS might modify, but it doesn't do the job. Apparently BIOS is not saving the context of some registers that aren't in this mask. Here's the original routine: CWadcHalf: ; ADC half buffer full ISR ; Hooked to HWI_INT18 in HWI module of GUI ; This calls the first decimation filter via SWI HWI_enter C55_AR_DR_BIOS_CONTEXT_MASK, C55_ACC_BIOS_CONTEXT_MASK, C55_MISC1_BIOS_CONTEXT_MASK, C55_MISC2_BIOS_CONTEXT_MASK, C55_MISC3_BIOS_CONTEXT_MASK, IER0DISABLEMASK, IER1DISABLEMASK AR1 = DMA_CSR0_IOPORT ; read DMA status to acknowledge XAR0 = #CWdecimate1 SWI_inc HWI_exit C55_AR_DR_BIOS_CONTEXT_MASK, C55_ACC_BIOS_CONTEXT_MASK, C55_MISC1_BIOS_CONTEXT_MASK, C55_MISC2_BIOS_CONTEXT_MASK, C55_MISC3_BIOS_CONTEXT_MASK, IER0RESTOREMASK, IER1RESTPREMASK Now here's how I changed it: CWadcHalf: ; ADC half buffer full ISR ; Hooked to HWI_INT18 in HWI module of GUI ; This calls the first decimation filter via SWI HWI_enter C55_ALL_AR_DR_REGS, C55_ACC_BIOS_CONTEXT_MASK, C55_MISC1_BIOS_CONTEXT_MASK, C55_MISC2_BIOS_CONTEXT_MASK, C55_MISC3_BIOS_CONTEXT_MASK, IER0DISABLEMASK, IER1DISABLEMASK AR1 = DMA_CSR0_IOPORT ; read DMA status to acknowledge XAR0 = #CWdecimate1 SWI_inc HWI_exit C55_ALL_AR_DR_REGS, C55_ACC_BIOS_CONTEXT_MASK, C55_MISC1_BIOS_CONTEXT_MASK, C55_MISC2_BIOS_CONTEXT_MASK, C55_MISC3_BIOS_CONTEXT_MASK, IER0RESTOREMASK, IER1RESTPREMASK Note that it is certainly DSP/BIOS screwing up, not my code. This HWI is the highest priority in my system, and the SWI that it posts can't run until the interrupt routine returns. Thanks again for the help. David L. Rick Hach Company |