|
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 |
|
|
Metrowerks Debugger SR I1 Mask Presented State
Started by ●January 30, 2003
Reply by ●January 30, 20032003-01-30
|
Hi Jay, and thanks very much for your very perceptive posting. I believe this issue was introduced by Metrowerks in response to several developers (including myself) complaining about the action of the system while trying to single-step the code from a breakpoint. Previously, if your system had any enabled interrupts at all, the debugger was virtually useless, because the instant that you tried to single-step, your program would start executing the interrupt code. Our systems have periodic timer interrupts at a 1-millisecond rate, which made single-stepping from a breakpoint completely impossible. Other processors I have used, such as the MC68302, have a pin that allows you to stop some of the internal peripherals like the timers, but the DSP56800 family does not have this feature. So, to cut to the chase, I believe that Metrowerks has come up with the best possible work-around for this hardware-related issue, which is to disable interrupts while you are debugging and single-stepping from breakpoints. The only thing they might possibly do, to improve the current operation of the debugger, is to show the value of the Status Register (SR) as it was _before_ the debugger disabled the interrupts. It certainly would (in my not-so-humble opinion) be counter-productive, to go back to the way the debugger used to operate, which was to leave the Interrupt 1 Mask (I1) state unchanged when you are trying to single-step from a breakpoint. Regards, Art Johnson Senior Systems Analyst PMC Prime Mover Controls Inc. 3600 Gilmore Way Burnaby, B.C., Canada V5G 4R8 Phone: 604 433-4644 FAX: 604 433-5570 Email: http://www.pmc-controls.com -----Original Message----- From: jepochert <> [mailto:] Sent: Thursday, January 30, 2003 10:00 AM To: Subject: [motoroladsp] Metrowerks Debugger SR I1 Mask Presented State 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 _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ |
Reply by ●January 31, 20032003-01-31
|
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 |
