Jay, We used to behave exactly the way that you want the debugger to behave (force the user to manually set the interrupt mask prior to single stepping) on previous releases and changed this behavior due to several customer inputs that debugging in a real application became too cumbersome due to the debugger being taken to isr code constantly (most commonly timer interrupts that would happen within short cycles). As far as the comment: ================================ >Does anyone like the fact that the debugger is indicating the > state of the I1 mask bit to the way your program should be behaving, > as if the tool was not interracting with the target at all? Or would > you rather have an accurate and true status displayed independent of > all tool interaction? ================================ We think this is what the customer would want, and this is not an isolated behavior as it is a similar case in how we handle software breakpoints. We assume that the customer would not want to see the "debug" instruction that the debugger inserts into the pipe, but rather your instruction in your code that is there instead. It goes along the same principle in terms of trying to give the customer what they want to see, it just seems that in this specific case you don't really agree with that. Perhaps you might like it if the debugger did not automatically modify the SR for you, and allowed you to choose this behavior. Currently we do it automatically, as most customers seemed to want this behavior, but if enough customers would like it as optional we can certainly consider that as a feature request as well. I will monitor the group here to see the response or you are more than welcome to submit the feature request yourself if you like. Regards, John --- In , "jepochert <jepochert@y...>" <jepochert@y...> wrote: > Hello all, > > We have recently discovered that the Metrowerks Debugger wants to > lie about the Status Register (SR) Interrupt 1 Mask (I1) state as > presented within its Register Status Display window. Let me first > qualify this a little. > > We are using the DSP56805 (rev F silicon) with the latest > CodeWarrior patch (v5.0.4). We are currently trying to wean > ourselves away from the Motorola SDK, at least the Board Support > Package (BSP) components, including the interrupt dispatcher. Even > though the dispatcher provides a great deal of safety and security, > the front end configuration with all the preprocessor specific > obfuscation is just not attractive. We are therefore writing our own > ISR's using the #pragma interrupt with both pre and post-amble calls > to archPushAllRegisters() and archPopAllRegisters() respectively. > > Thus far, all of our development has been quite successful. We > have somehow stayed away from all the interrupt issues as previous > postings have indicated. I believe this to be that we haven't > embarked on this quest until after the 5.0.3 patch which seems to > have fixed the Hardware Stack / DO Loop problems. > > Anyway, back to the subject. While unit level testing various > code, we had noticed that the SR I1 bit properly indicates a zero, > when not in an ISR. However, something sinister would occur whenever > we executed the following routine: > > asm int GetSR(void) > { > move SR,Y0 > } > > the destination register ALWAYS indicates the I1 Mask bit set! I had > further noticed that if the following code snipped it used instead: > > asm int GetSR(void) > { > move X:(SP),Y0 > } > > the return value (Y0) is correct! > > NOTE: Even though a jsr pushes both the PC and the SR, the rts > pops but discards (does not restore) the SR upon return. Thus, the > value of the SR is known and available to the routine from the stack > (SP). > > To make a long story short, we have discovered (along with some > help from Motorola Tech Support), that the debugger is doing us a > favor of lying about the state of the SR I1 Mask bit within it's > Register Display window. > > In both cases above, the breakpoint is set at the address of the > move instruction. Upon further inspection, if you step into this > routine, the return value is again wrong (I1 ALWAYS set), independent > of whether this code is called from an ISR or not. It has been > determined that the debugger is automagically setting the I1 Mask (at > the breakpoint) but still indicating the SR I1 Mask as clear in the > register display window. I believe this potentially maybe based on > the tool designers intent to allow single-stepping to occur without > having to service any pended interrupts while in the halted debugged > state. > > However, all other debuggers that I have ever used left this > exercise up to the user in that he or she must manually set the > interrupt mask prior to single-stepping in order to ignore all pended > IRQ's. > > Am I missing something? Is anyone else not comfortable with this > functionality? I am reluctant to submit an issue report to > Metrowerks on the off chance that I may be in the minority. > > Does anyone like the fact that the debugger is indicating the > state of the I1 mask bit to the way your program should be behaving, > as if the tool was not interracting with the target at all? Or would > you rather have an accurate and true status displayed independent of > all tool interaction? > > I'll await to see some opinions before declaring this an issue and > putting any pressure on Metrowerks for a change. > > Jay Pochert > Sr. Software Engineer > Qualstar Corporation > Advanced Product Development > (303)444-1101 x119 |