Post by thread:[PIC]:Mplab ICE 2000 Complex triggers

I'm getting some anomalous behaviour. Basically, I have a routine that has four points where it could "panic" and abort. For debugging, I've put four different labels at the panic exit point, and used different gotos as below: (some code) btfss port,bit goto panic_a (more code) btfsc port,bit goto panic_b (more code) btfss port,bit goto panic_c (more code) btfsc port,bit goto panic_d (More normal code) return ;normal exit panic_a: panic_b: panic_c: panic_d: (panic code) return ; panic exit. So, I put complex triggers on each of the panic gotos, so I can trigger my scope when they occur. That worked just fine. However, later, I commented out panic_a and panic_c. When I breakpoint, and pull up the trace memory, it shows that I came through panic_a, which now looks like this: (some code) ;btfss port,bit ;goto panic_a I did re-assemble, reset, and run, and I even tried closing the entire project and coming back in. Still, according to the trace, it's getting to the panic code, via panic_a. It's difficult to debug, when you get things like this. -- Dave's Engineering Page: http://www.dvanhorn.org Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

On Fri, 11 May 2001, David VanHorn wrote: > I'm getting some anomalous behaviour. <SNIP> > However, later, I commented out panic_a and panic_c. > When I breakpoint, and pull up the trace memory, it shows that I came > through panic_a, which now looks like this: > > (some code) > ;btfss port,bit > ;goto panic_a > > I did re-assemble, reset, and run, and I even tried closing the entire > project and coming back in. > Still, according to the trace, it's getting to the panic code, via panic_a. Just a random thought, but did you comment out the panic_a label? David W. Gulley Destiny Designs -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu

At 11:29 AM 5/11/01 -0700, David W. Gulley wrote: >On Fri, 11 May 2001, David VanHorn wrote: > > I'm getting some anomalous behaviour. ><SNIP> > > However, later, I commented out panic_a and panic_c. > > When I breakpoint, and pull up the trace memory, it shows that I came > > through panic_a, which now looks like this: > > > > (some code) > > ;btfss port,bit > > ;goto panic_a > > > > I did re-assemble, reset, and run, and I even tried closing the entire > > project and coming back in. > > Still, according to the trace, it's getting to the panic code, via panic_a. > >Just a random thought, but did you comment out the panic_a label? no, but according to the trace, it's executing the commented line "goto panic_a" -- Dave's Engineering Page: http://www.dvanhorn.org Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu

Dear David VanHorn, David VanHorn <.....dvanhornKILLspam.....CEDAR.NET> on 2001-05-11 11:11:29 AM > When I breakpoint, and pull up the trace memory, it shows that I came > through panic_a, which now looks like this: > > (some code) > ;btfss port,bit > ;goto panic_a > > I did re-assemble, reset, and run, and I even tried closing the entire > project and coming back in. > Still, according to the trace, it's getting to the panic code, via panic_a. In MPLAB, when I see things like this, I do Ctrl+F10 (re-build every file -- when I modify an include file the normal "build" doesn't catch it) Program Reset Run It sounds like it hasn't been programmed with your latest version. Can you read-out the ROM and see that it really has what you think it does ? -- David Cary -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu

> >In MPLAB, when I see things like this, I do > Ctrl+F10 > (re-build every file -- when I modify an include file the normal "build" >doesn't catch it) > Program > Reset > Run That's what I do every time. Building less than all never made sense to me. Takes all of about 5 sec to assemble. >It sounds like it hasn't been programmed with your latest version. >Can you read-out the ROM and see that it really has what you think it does ? Yes. The code that I make is what's in the chip. -- Dave's Engineering Page: http://www.dvanhorn.org Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspam_OUTmitvma.mit.edu

Hi David and everyone.. > no, but according to the trace, it's executing the commented > line "goto > panic_a" I'm not too familiar with MPLAB, but perhaps it is because the assembler or debugger only "remembers" the first label for a location it finds.. panaic_a is the first one, the rest also happen to point to the same location, but it probably looks that location up in a table and finds "panic_a" when it comes to the goto statement in the debugger. Try separating the labels with NOPs to force different location: panic_a: NOP panic_b: NOP panic_c: NOP panic_d: (panic code) Hope this helps, Ash. -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

At 08:14 PM 5/11/01 -0400, Bob Ammerman wrote: >David: > >I am pretty sure the history buffer is displayed using disassembly, as >opposed to grabbing lines from the source code. Is this right? > >If that is the case then, given that 'panic_a', 'panic_b', 'panic_c' and >'panic_d' all label the same location, the dissambly can't tell them apart. Yeabut. I thought of that, so I made the target like this: Panic_a: movlw 1 Panic_b: movlw 2 etc. The thing is, I'll end up somewhere in the middle of that, but in the trace, is the "goto Panic_a" instruction, which has a semicolon in front of it! The key seems to be, that I made the triggers, then commented them out. Apparently, if it's a complex breakpoint, it can't be commented out .. At least that's how it seems to me. I've reported it to Mchip. -- Dave's Engineering Page: http://www.dvanhorn.org Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu

David VanHorn wrote: {Quote hidden}> > At 11:29 AM 5/11/01 -0700, David W. Gulley wrote: > >On Fri, 11 May 2001, David VanHorn wrote: > > > I'm getting some anomalous behaviour. > ><SNIP> > > > However, later, I commented out panic_a and panic_c. > > > When I breakpoint, and pull up the trace memory, it shows that I came > > > through panic_a, which now looks like this: > > > > > > (some code) > > > ;btfss port,bit > > > ;goto panic_a > > > > > > I did re-assemble, reset, and run, and I even tried closing the entire > > > project and coming back in. > > > Still, according to the trace, it's getting to the panic code, via panic_a. > > > >Just a random thought, but did you comment out the panic_a label? > > no, but according to the trace, it's executing the commented line "goto > panic_a" David, the IDE doesn't handle stacked (overloaded) goto labels very well. If you have two labels with one line of code, (like if you comment-out the code but leave a label) the MPLAB IDE will decide which label it will accept for debugging etc. Have a look at the code in the ROM window, then top left button of it to select "dissassembly display" then you can see which of the labels the debugger has used. I imagine it always uses the first (or last) label if they are stacked. I don't know which because I try to avoid stacking labels for exactly the reason you have now! :o) -Roman -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

At 04:52 PM 5/12/01 +1000, Roman Black wrote: {Quote hidden}>David VanHorn wrote: > > > > At 11:29 AM 5/11/01 -0700, David W. Gulley wrote: > > >On Fri, 11 May 2001, David VanHorn wrote: > > > > I'm getting some anomalous behaviour. > > ><SNIP> > > > > However, later, I commented out panic_a and panic_c. > > > > When I breakpoint, and pull up the trace memory, it shows that I came > > > > through panic_a, which now looks like this: > > > > > > > > (some code) > > > > ;btfss port,bit > > > > ;goto panic_a > > > > > > > > I did re-assemble, reset, and run, and I even tried closing the entire > > > > project and coming back in. > > > > Still, according to the trace, it's getting to the panic code, via > panic_a. > > > > > >Just a random thought, but did you comment out the panic_a label? > > > > no, but according to the trace, it's executing the commented line "goto > > panic_a" > > >David, the IDE doesn't handle stacked (overloaded) >goto labels very well. If you have two labels with >one line of code, (like if you comment-out the code >but leave a label) the MPLAB IDE will decide which >label it will accept for debugging etc. OK, but the problem isn't there. When the only line of source in the project that reads: "goto panic_a" has a semicolon in front of it, then it had better not show up in a trace. The problem appears to be that I had a complex trigger defined on this line, and then commented it out (and rebuilt the entire project) It seems that the complex trigger somehow overrides the commenting. >Have a look at the code in the ROM window, then top >left button of it to select "dissassembly display" >then you can see which of the labels the debugger >has used. I imagine it always uses the first (or last) >label if they are stacked. I don't know which because >I try to avoid stacking labels for exactly the reason >you have now! :o) The stacked labels weren't the problem. -- Dave's Engineering Page: http://www.dvanhorn.org Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> The key seems to be, that I made the triggers, then commented them out. > Apparently, if it's a complex breakpoint, it can't be commented out .. > At least that's how it seems to me. Geesh, Dave. And you still expect it give you the right trace after that!? That's asking an awful lot. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, RemoveMEolinTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> When the only line of source in the project that reads: > "goto panic_a" has a semicolon in front of it, then it had better not show > up in a trace. Not so. It could show up if you have GOTO PANIC_B, and PANIC_B = PANIC_A. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, spamBeGoneolinspamBeGoneembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

At 05:40 PM 5/12/01 -0400, Olin Lathrop wrote: > > The key seems to be, that I made the triggers, then commented them out. > > Apparently, if it's a complex breakpoint, it can't be commented out .. > > At least that's how it seems to me. > >Geesh, Dave. And you still expect it give you the right trace after that!? >That's asking an awful lot. I'm a picky bastard, for some reason, I expect it to execute the code I wrote, with no additions or deletions. :) -- Dave's Engineering Page: http://www.dvanhorn.org Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads