|
Hello everyone - I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled by the Metrowerks True-Time debugger. I have been developing code for a few months now. Most of the time everything works fine. But every now and then (between several minutes to a few hours), the processor simply halts. In every case the True-Time debugger indicates that the processor has halted on the BGND instruction in the Unimplemented ISR trap. I modified the isr_vectors.c file to produce a unique (but identical) routine for each of the 64 vectors. This allowed me to identify that the trap occurs on Unimplemented ISR 63, whose vector is mapped to address 0xFF80. The MC9S12DT128B Device User Guide indicates that the vector at address 0xFF80 is "Reserved." It is not assigned to any documented function. Therefore, I would expect that this vector would never be seen. I have only seen this behavior with the BDM-Multilink connected to my target. I don't know if it will happen when the target is running standalone. The problem occurs so infrequently that I really can't just sit around and wait for it to happen. Of course with an in-circuit emulator, I could set up a trace to see the executed instructions leading up to the interrupt. But alas, all I have is the humble BDM-Multilink. Anyone have any ideas about why this might be happening, or how I might debug it? Thanks. Andy |
|
|
Trap on Unimplemented ISR
Started by ●August 22, 2003
Reply by ●August 22, 20032003-08-22
Reply by ●August 25, 20032003-08-25
|
Hi Andy. Can you make sure that when the debugger halts, the I bit is set? I mean that the debugger will halt on any BGND instruction execution. A jump to this address would do the same thing. But only an interrupt will set I. I can imaging that the PC has "quitted" the program and incremented till reaching address FF80 and halted the debugger this way. Typically, the debugger is able to read the program call chain on the device stack and display it in the Procedure window: If an interrupt occurs, you should be able to find latest procedure called. Best regards, Gilles At 11:10 PM 8/22/2003, you wrote: >Hello everyone - > >I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled by the >Metrowerks True-Time debugger. I have been developing code for a few >months now. > >Most of the time everything works fine. But every now and then (between >several minutes to a few hours), the processor simply halts. In every case >the True-Time debugger indicates that the processor has halted on the BGND >instruction in the Unimplemented ISR trap. > >I modified the isr_vectors.c file to produce a unique (but identical) >routine for each of the 64 vectors. This allowed me to identify that the >trap occurs on Unimplemented ISR 63, whose vector is mapped to address 0xFF80. > >The MC9S12DT128B Device User Guide indicates that the vector at address >0xFF80 is "Reserved." It is not assigned to any documented >function. Therefore, I would expect that this vector would never be seen. > >I have only seen this behavior with the BDM-Multilink connected to my >target. I don't know if it will happen when the target is running >standalone. The problem occurs so infrequently that I really can't just >sit around and wait for it to happen. > >Of course with an in-circuit emulator, I could set up a trace to see the >executed instructions leading up to the interrupt. But alas, all I have is >the humble BDM-Multilink. > >Anyone have any ideas about why this might be happening, or how I might >debug it? > >Thanks. > >Andy > > >-------------------- > >">http://docs.yahoo.com/info/terms/ |
|
|
Reply by ●September 4, 20032003-09-04
|
Gilles - Good idea. The next time this happens, I will check the I bit and the stack, which might yield further clues as to what is happening. But I don't think a runaway processor would halt if it tried to execute the contents of 0xFF80 - this location would contain the address of the Unimplemented ISR service routine, and not the BGND instruction itself. The service routine for Unimplemented ISR 63 occurs in memory AFTER all of the other Unimplemented ISR routines (all of which contain simply a single BGND instruction) - this is the last BGND instruction, not the first. Therefore, it seems unlikely to me that the processor was executing runaway code and "happened" upon the BGND instruction. Though it is plausible that there might be a jump to that location. Thanks for the reply. Andy ---------------------------- --- In , Gilles Blanquin <gblanquin@m...> wrote: > Hi Andy. > > Can you make sure that when the debugger halts, the I bit is set? > I mean that the debugger will halt on any BGND instruction execution. A > jump to this address would do the same thing. But only an interrupt will set I. > > I can imaging that the PC has "quitted" the program and incremented till > reaching address FF80 and halted the debugger this way. > > Typically, the debugger is able to read the program call chain on the > device stack and display it in the Procedure window: If an interrupt > occurs, you should be able to find latest procedure called. > Best regards, > Gilles > At 11:10 PM 8/22/2003, you wrote: > > >Hello everyone - > > > >I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled by the > >Metrowerks True-Time debugger. I have been developing code for a few > >months now. > > > >Most of the time everything works fine. But every now and then (between > >several minutes to a few hours), the processor simply halts. In every case > >the True-Time debugger indicates that the processor has halted on the BGND > >instruction in the Unimplemented ISR trap. > > > >I modified the isr_vectors.c file to produce a unique (but identical) > >routine for each of the 64 vectors. This allowed me to identify that the > >trap occurs on Unimplemented ISR 63, whose vector is mapped to address 0xFF80. > > > >The MC9S12DT128B Device User Guide indicates that the vector at address > >0xFF80 is "Reserved." It is not assigned to any documented > >function. Therefore, I would expect that this vector would never be seen. > > > >I have only seen this behavior with the BDM-Multilink connected to my > >target. I don't know if it will happen when the target is running > >standalone. The problem occurs so infrequently that I really can't just > >sit around and wait for it to happen. > > > >Of course with an in-circuit emulator, I could set up a trace to see the > >executed instructions leading up to the interrupt. But alas, all I have is > >the humble BDM-Multilink. > > > >Anyone have any ideas about why this might be happening, or how I might > >debug it? > > > >Thanks. > > > >Andy > > > > > > > > > >-------------------- > > > > > > > |
|
|
Reply by ●September 5, 20032003-09-05
|
Hi Andy! Oops! Sorry for this hilarious suggestion. I might have been seriously tired that day. For sure, above 0xFF7F, there might be only vectors, no BNGD and no trap ISRs. An emulator would be nice to debug this. Also if you could port/test your code on an MC9S12 "E" part (or any device featuring the DBG module), http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MC9S12E128&n odeIdt3ZGpnLn8636K100 it features the DBG12 module i.e advanced triggers + "change-of-flow" trace buffer. http://e-www.motorola.com/files/microcontrollers/doc/ref_manual/S12DBGV1.pdf Best regards, Gilles At 07:18 PM 9/4/2003, you wrote: >Gilles - > >Good idea. The next time this happens, I will check the I bit and >the >stack, which might yield further clues as to what is happening. > >But I don't think a runaway processor would halt if it tried to >execute the contents of 0xFF80 - this location would contain the >address of the Unimplemented ISR service routine, and not the BGND >instruction itself. The service routine for Unimplemented ISR 63 >occurs in memory AFTER all of the other Unimplemented ISR routines >(all of which contain simply a single BGND instruction) - this is the >last BGND instruction, not the first. Therefore, it seems unlikely >to >me that the processor was executing runaway code and "happened" upon >the BGND instruction. Though it is plausible that there might be a >jump to that location. > >Thanks for the reply. > >Andy > >---------------------------- >--- In , Gilles Blanquin <gblanquin@m...> wrote: > > Hi Andy. > > > > Can you make sure that when the debugger halts, the I bit is set? > > I mean that the debugger will halt on any BGND instruction >execution. A > > jump to this address would do the same thing. But only an interrupt >will set I. > > > > I can imaging that the PC has "quitted" the program and incremented >till > > reaching address FF80 and halted the debugger this way. > > > > Typically, the debugger is able to read the program call chain on >the > > device stack and display it in the Procedure window: If an >interrupt > > occurs, you should be able to find latest procedure called. > > > > > > Best regards, > > Gilles > > > > > > At 11:10 PM 8/22/2003, you wrote: > > > > >Hello everyone - > > > > > >I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled >by the > > >Metrowerks True-Time debugger. I have been developing code for a >few > > >months now. > > > > > >Most of the time everything works fine. But every now and then >(between > > >several minutes to a few hours), the processor simply halts. In >every case > > >the True-Time debugger indicates that the processor has halted on >the BGND > > >instruction in the Unimplemented ISR trap. > > > > > >I modified the isr_vectors.c file to produce a unique (but >identical) > > >routine for each of the 64 vectors. This allowed me to identify >that the > > >trap occurs on Unimplemented ISR 63, whose vector is mapped to >address 0xFF80. > > > > > >The MC9S12DT128B Device User Guide indicates that the vector at >address > > >0xFF80 is "Reserved." It is not assigned to any documented > > >function. Therefore, I would expect that this vector would never >be seen. > > > > > >I have only seen this behavior with the BDM-Multilink connected to >my > > >target. I don't know if it will happen when the target is running > > >standalone. The problem occurs so infrequently that I really >can't >just > > >sit around and wait for it to happen. > > > > > >Of course with an in-circuit emulator, I could set up a trace to >see the > > >executed instructions leading up to the interrupt. But alas, all >I >have is > > >the humble BDM-Multilink. > > > > > >Anyone have any ideas about why this might be happening, or how I >might > > >debug it? > > > > > >Thanks. > > > > > >Andy > > > > > > > > > > > > > > >-------------------- > > > > > > > > > > > > >-------------------- > >">http://docs.yahoo.com/info/terms/ |
Reply by ●October 6, 20032003-10-06
|
OK, now the problem seems to have morphed into something repeatable. I wrote some test code to solve another problem, that repeatedly calls one routine to read data from a proprietary input port, and transmit that data to a serial output port for viewing with Hyperterminal. This code appears to work fine. But, the debugger does the following. (Note: I am using MC9S12DG128B, P&E BDM Multilink, and Metrowerks True-Time debugger.) 1. I click Start in the True-Time debugger, which starts up my code at the Reset vector, using the BDM-Multilink. The target program starts to run correctly, and I start seeing data appearing on Hyperterminal. 2. After a second or so, the debugger appears to halt on the BGND instruction in the service routine for Unimplemented ISR 63, whose vector is mapped to address 0xFF80. However, the program continues to run properly on the target. Only the debugger has stopped. The Halt button on the debugger toolbar is grayed-out and not available. 3. If I click on the Start button in the toolbar, nothing appears to happen. The program continues to run on the target. 4. If I scroll through memory within the debugger while the program is running and the debugger is in this halted state, it all reads FF. All of the HC12 registers read FF, too, as does the CCR. 5. If I click on the Reset Target button on the toolbar, the program in the target halts, and the debugger returns to its normal state. I can then see the actual memory in the target, and the actual state of the registers. Any clues, I'd appreciate your ideas. Thanks everyone. Andy ------------------------------ --- In , "Sifferman" <asifferm@a...> wrote: > > Gilles - > > Good idea. The next time this happens, I will check the I bit and > the > stack, which might yield further clues as to what is happening. > > But I don't think a runaway processor would halt if it tried to > execute the contents of 0xFF80 - this location would contain the > address of the Unimplemented ISR service routine, and not the BGND > instruction itself. The service routine for Unimplemented ISR 63 > occurs in memory AFTER all of the other Unimplemented ISR routines > (all of which contain simply a single BGND instruction) - this is the > last BGND instruction, not the first. Therefore, it seems unlikely > to > me that the processor was executing runaway code and "happened" upon > the BGND instruction. Though it is plausible that there might be a > jump to that location. > > Thanks for the reply. > > Andy > > ---------------------------- > --- In , Gilles Blanquin <gblanquin@m...> wrote: > > Hi Andy. > > > > Can you make sure that when the debugger halts, the I bit is set? > > I mean that the debugger will halt on any BGND instruction > execution. A > > jump to this address would do the same thing. But only an interrupt > will set I. > > > > I can imaging that the PC has "quitted" the program and incremented > till > > reaching address FF80 and halted the debugger this way. > > > > Typically, the debugger is able to read the program call chain on > the > > device stack and display it in the Procedure window: If an > interrupt > > occurs, you should be able to find latest procedure called. > > > > > > Best regards, > > Gilles > > > > > > At 11:10 PM 8/22/2003, you wrote: > > > > >Hello everyone - > > > > > >I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled > by the > > >Metrowerks True-Time debugger. I have been developing code for a > few > > >months now. > > > > > >Most of the time everything works fine. But every now and then > (between > > >several minutes to a few hours), the processor simply halts. In > every case > > >the True-Time debugger indicates that the processor has halted on > the BGND > > >instruction in the Unimplemented ISR trap. > > > > > >I modified the isr_vectors.c file to produce a unique (but > identical) > > >routine for each of the 64 vectors. This allowed me to identify > that the > > >trap occurs on Unimplemented ISR 63, whose vector is mapped to > address 0xFF80. > > > > > >The MC9S12DT128B Device User Guide indicates that the vector at > address > > >0xFF80 is "Reserved." It is not assigned to any documented > > >function. Therefore, I would expect that this vector would never > be seen. > > > > > >I have only seen this behavior with the BDM-Multilink connected to > my > > >target. I don't know if it will happen when the target is running > > >standalone. The problem occurs so infrequently that I really > can't > just > > >sit around and wait for it to happen. > > > > > >Of course with an in-circuit emulator, I could set up a trace to > see the > > >executed instructions leading up to the interrupt. But alas, all > I > have is > > >the humble BDM-Multilink. > > > > > >Anyone have any ideas about why this might be happening, or how I > might > > >debug it? > > > > > >Thanks. > > > > > >Andy > > > > > > > > > > > > > > >-------------------- > > > > > > > > > > > > |
|
|
Reply by ●October 7, 20032003-10-07
|
Hi Andy. Thanks for isolating this problem. All points after "point 2" are "normal", resulting from a loss of communication. This is a "hardware" problem. It seems to be something bound to bus speed change via onchip PLL, implying also a BDM communication speed change and loss of communication/synchronization between the chip and the Multilink. If your application changes (even only once) the bus speed via PLL: -make sure a PLL Loop Filter is installed. -check the "set CLKSW bit in BDM control register (MC9S12 only)" checkbox in the "Communication Device Specification" dialog (menu: "ICD-12" then "Connect..."). If you open a "Command" component, speed variation detections by the cable should be reported there. Andy, you can send me your program/project directly. Please specify also the MC9S12DG128B silicon mask, the Multilink cable revision, and also your Metrowerks CodeWarrior version. Typing "ver" in the "Command" window gives directly a list of DLL versions. Any other info like schematics is also welcome. Thanks for all your help. Regards, Gilles At 11:39 PM 10/6/2003, you wrote: >OK, now the problem seems to have morphed into something repeatable. >I wrote some test code to solve another problem, that repeatedly calls >one routine to read data from a proprietary input port, and transmit >that data to a serial output port for viewing with Hyperterminal. >This code appears to work fine. But, the debugger does the following. >(Note: I am using MC9S12DG128B, P&E BDM Multilink, and Metrowerks >True-Time debugger.) > >1. I click Start in the True-Time debugger, which starts up my code at >the Reset vector, using the BDM-Multilink. The target program starts >to run correctly, and I start seeing data appearing on Hyperterminal. > >2. After a second or so, the debugger appears to halt on the BGND >instruction in the service routine for Unimplemented ISR 63, whose >vector is mapped to address 0xFF80. However, the program continues to >run properly on the target. Only the debugger has stopped. The Halt >button on the debugger toolbar is grayed-out and not available. > >3. If I click on the Start button in the toolbar, nothing appears to >happen. The program continues to run on the target. > >4. If I scroll through memory within the debugger while the program is >running and the debugger is in this halted state, it all reads FF. >All of the HC12 registers read FF, too, as does the CCR. > >5. If I click on the Reset Target button on the toolbar, the program >in the target halts, and the debugger returns to its normal state. I >can then see the actual memory in the target, and the actual state of >the registers. > >Any clues, I'd appreciate your ideas. > >Thanks everyone. > >Andy > >------------------------------ >--- In , "Sifferman" <asifferm@a...> wrote: > > > > Gilles - > > > > Good idea. The next time this happens, I will check the I bit and > > the > > stack, which might yield further clues as to what is happening. > > > > But I don't think a runaway processor would halt if it tried to > > execute the contents of 0xFF80 - this location would contain the > > address of the Unimplemented ISR service routine, and not the BGND > > instruction itself. The service routine for Unimplemented ISR 63 > > occurs in memory AFTER all of the other Unimplemented ISR routines > > (all of which contain simply a single BGND instruction) - this is >the > > last BGND instruction, not the first. Therefore, it seems unlikely > > to > > me that the processor was executing runaway code and "happened" upon > > the BGND instruction. Though it is plausible that there might be a > > jump to that location. > > > > Thanks for the reply. > > > > Andy > > > > ---------------------------- > > --- In , Gilles Blanquin <gblanquin@m...> >wrote: > > > Hi Andy. > > > > > > Can you make sure that when the debugger halts, the I bit is set? > > > I mean that the debugger will halt on any BGND instruction > > execution. A > > > jump to this address would do the same thing. But only an >interrupt > > will set I. > > > > > > I can imaging that the PC has "quitted" the program and >incremented > > till > > > reaching address FF80 and halted the debugger this way. > > > > > > Typically, the debugger is able to read the program call chain on > > the > > > device stack and display it in the Procedure window: If an > > interrupt > > > occurs, you should be able to find latest procedure called. > > > > > > > > > Best regards, > > > Gilles > > > > > > > > > At 11:10 PM 8/22/2003, you wrote: > > > > > > >Hello everyone - > > > > > > > >I am using the MC9S12DG128B with the P&E BDM-Multilink, >controlled > > by the > > > >Metrowerks True-Time debugger. I have been developing code for a > > few > > > >months now. > > > > > > > >Most of the time everything works fine. But every now and then > > (between > > > >several minutes to a few hours), the processor simply halts. In > > every case > > > >the True-Time debugger indicates that the processor has halted on > > the BGND > > > >instruction in the Unimplemented ISR trap. > > > > > > > >I modified the isr_vectors.c file to produce a unique (but > > identical) > > > >routine for each of the 64 vectors. This allowed me to identify > > that the > > > >trap occurs on Unimplemented ISR 63, whose vector is mapped to > > address 0xFF80. > > > > > > > >The MC9S12DT128B Device User Guide indicates that the vector at > > address > > > >0xFF80 is "Reserved." It is not assigned to any documented > > > >function. Therefore, I would expect that this vector would never > > be seen. > > > > > > > >I have only seen this behavior with the BDM-Multilink connected >to > > my > > > >target. I don't know if it will happen when the target is >running > > > >standalone. The problem occurs so infrequently that I really > > can't > > just > > > >sit around and wait for it to happen. > > > > > > > >Of course with an in-circuit emulator, I could set up a trace to > > see the > > > >executed instructions leading up to the interrupt. But alas, all > > I > > have is > > > >the humble BDM-Multilink. > > > > > > > >Anyone have any ideas about why this might be happening, or how I > > might > > > >debug it? > > > > > > > >Thanks. > > > > > > > >Andy > > > > > > > > > > > > > > > > > > > >-------------------- > > > > > > > > > > > > > > > > >-------------------- > >">http://docs.yahoo.com/info/terms/ |
|
|
Reply by ●October 10, 20032003-10-10
|
--- In , Gilles Blanquin <gblanquin@m...> wrote: Hi Giles, > If your application changes (even only once) the bus speed via PLL: > -make sure a PLL Loop Filter is installed. What is? Hardware? Sodtware? Regards, Theo |
|
|
Reply by ●October 12, 20032003-10-12
|
Theo, The PLL Loop Filter is the name of a network of 2 capacitors and one resistors that should be connected to the Xfc pin of your HC12 / HCS12, if you want to activate and use the internal HC12 PLL. In order to calculate the values of the capacitors and resistor for the HCS12 parts, you can download and use the following program from the Nohau web-site: http://www.nohau.com/s12calc/pll_302.html Hope this helps, Doron Nohau Corporation HC12 In-Circuit Emulators www.nohau.com/emul12pc.html At 19:49 10/10/2003 +0000, you wrote: >--- In , Gilles Blanquin <gblanquin@m...> wrote: > >Hi Giles, > > > If your application changes (even only once) the bus speed via PLL: > > -make sure a PLL Loop Filter is installed. > >What is? > >Hardware? Sodtware? >Regards, > >Theo |
|
|
Reply by ●October 12, 20032003-10-12
|
--- In , Doron Fael <doronf@n...> wrote: Hi Doron, Thanks for that, hadn't come accross the name. Steep learning curve from 6800 to HC12:-) Regards, Theo > The PLL Loop Filter is the name of a network of 2 capacitors and one > resistors that should be connected to the Xfc pin of your HC12 / HCS12, if > you want to activate and use the internal HC12 PLL. > > In order to calculate the values of the capacitors and resistor for the > HCS12 parts, you can download and use the following program from the Nohau > web-site: > http://www.nohau.com/s12calc/pll_302.html > > Hope this helps, > Doron > Nohau Corporation > HC12 In-Circuit Emulators > www.nohau.com/emul12pc.html > > At 19:49 10/10/2003 +0000, you wrote: > >--- In , Gilles Blanquin <gblanquin@m...> wrote: > > > >Hi Giles, > > > > > If your application changes (even only once) the bus speed via PLL: > > > -make sure a PLL Loop Filter is installed. > > > >What is? > > > >Hardware? Sodtware? > > > > > >Regards, > > > >Theo > |
