|
I'm fairly new to using the HC12. The tools I'm using is
CodeWarrior and the Multilink BDM. The BDM doesn't seem to be working correctly as a debugging tool. Breakpoints only seem to work sporadically and when I try to single step the processor seems to jump off into never, never land. Am I doing something wrong or is the BDM pretty useless as a debugger? Any ideas? |
|
|
BDM problems
Started by ●April 23, 2004
Reply by ●April 23, 20042004-04-23
|
Mike: I have faced similar issues in a project where I had hardware interrupts happening independent of software control. When you have this situation you must do the following: 1.. Set a breakpoint 2.. When breakpoint occurs you must disable further interrupts. I use the P&E debugger ICD12Z and they have a simple way to disable interrupts by clicking on the I flag in their flag register which is always visible. 3.. After interrupts are disabled, I can single step as much as I want or cause the processor to run to the cursor etc. Hope this helps .... Steve Dillier HighPoint Technology ----- Original Message ----- From: Mike Elphick To: Sent: Friday, April 23, 2004 9:47 AM Subject: Re: [68HC12] BDM problems I don't use the same tools as yourself, but I too have had problems with getting breakpoints to work, sometimes having to set two, one after the other. Of course you need to be careful where you put them. I've spent ages sometimes only to find that part of the program never gets executed! Also, it probably won't work if you put a breakpoint in the middle of a line of code. One thing that you should do is to inhibit interrupts; maybe this is where your program is flying off too. Personally, I do this by not calling any initialisation routines that set up an interrupt, but there are other techniques. Mike. ----- Original Message ----- From: "dvarese" <> To: <> Sent: Friday, April 23, 2004 2:34 PM Subject: [68HC12] BDM problems > I'm fairly new to using the HC12. The tools I'm using is CodeWarrior > and the Multilink BDM. The BDM doesn't seem to be working correctly > as a debugging tool. Breakpoints only seem to work sporadically and > when I try to single step the processor seems to jump off into never, > never land. Am I doing something wrong or is the BDM pretty useless > as a debugger? Any ideas? > > --------------------To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > o learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > > > -- ------ > Yahoo! Groups Links > > a.. To --------------------To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu o learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu ------ Yahoo! Groups Links a.. To |
Reply by ●April 23, 20042004-04-23
|
I don't use the same tools as yourself, but I too have had problems
with getting breakpoints to work, sometimes having to set two, one after the other. Of course you need to be careful where you put them. I've spent ages sometimes only to find that part of the program never gets executed! Also, it probably won't work if you put a breakpoint in the middle of a line of code. One thing that you should do is to inhibit interrupts; maybe this is where your program is flying off too. Personally, I do this by not calling any initialisation routines that set up an interrupt, but there are other techniques. Mike. ----- Original Message ----- From: "dvarese" <> To: <> Sent: Friday, April 23, 2004 2:34 PM Subject: [68HC12] BDM problems > I'm fairly new to using the HC12. The tools I'm using is CodeWarrior > and the Multilink BDM. The BDM doesn't seem to be working correctly > as a debugging tool. Breakpoints only seem to work sporadically and > when I try to single step the processor seems to jump off into never, > never land. Am I doing something wrong or is the BDM pretty useless > as a debugger? Any ideas? > > --------------------To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > o learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > > > -- ------ > Yahoo! Groups Links > > a.. To |
|
|
Reply by ●April 23, 20042004-04-23
|
--- In , "Mike Elphick" <mike.elphick@d...> wrote: > I don't use the same tools as yourself, but I too have had problems with > getting breakpoints to work, sometimes having to set two, one after the > other. Of course you need to be careful where you put them. I've spent > ages sometimes only to find that part of the program never gets executed! > Also, it probably won't work if you put a breakpoint in the middle of a line > of code. I use a Compod12 and NoIce, programming is in assembly and I never experienced the problems you describe. Even the interrupts are ignored when single stepping when the step over key is use. Solidly performancing combination, fairly cheap as well. Cheers, Theo |
Reply by ●April 23, 20042004-04-23
|
Don: You may be having communication issues. Are you using a standard development board, or one of your own design? Ensure that you have pull-ups on the RESET and BKGD lines. If you're still having problems, please feel free to contact me off-list so we can get you up and running. Regards, Mark P&E dvarese wrote: >I'm fairly new to using the HC12. The tools I'm using is CodeWarrior >and the Multilink BDM. The BDM doesn't seem to be working correctly >as a debugging tool. Breakpoints only seem to work sporadically and >when I try to single step the processor seems to jump off into never, >never land. Am I doing something wrong or is the BDM pretty useless >as a debugger? Any ideas? > > >--------------------To learn more about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu >o learn more about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu > >Yahoo! Groups Links -- ____________________________ Mark L. Cukier, Design Engineer P&E Microcomputer Systems 710 Commonwealth Avenue Boston, MA 02215 _________________________________ e-mail: phone : (617) 353-9206 x19 fax : (617) 353-9205 _________________________________ visit us on the web at: http: //www.pemicro.com |
Reply by ●April 23, 20042004-04-23
|
Hi Steve, I was aware that something like this was possible, but have not tried it yet. Next time.... Thanks and regards, Mike. ----- Original Message ----- From: "Steve-HighPoint" <> To: <> Sent: Friday, April 23, 2004 3:44 PM Subject: Re: [68HC12] BDM problems > Mike: > > I have faced similar issues in a project where I had hardware interrupts happening independent of software control. When you have this situation you must do the following: > 1.. Set a breakpoint > 2.. When breakpoint occurs you must disable further interrupts. I use the P&E debugger ICD12Z and they have a simple way to disable interrupts by clicking on the I flag in their flag register which is always visible. > 3.. After interrupts are disabled, I can single step as much as I want or cause the processor to run to the cursor etc. > Hope this helps .... > > Steve Dillier > HighPoint Technology |
Reply by ●April 23, 20042004-04-23
|
>I'm fairly new to using the HC12. The tools I'm using is CodeWarrior >and the Multilink BDM. The BDM doesn't seem to be working correctly >as a debugging tool. Breakpoints only seem to work sporadically and >when I try to single step the processor seems to jump off into never, >never land. Am I doing something wrong or is the BDM pretty useless >as a debugger? Any ideas? BDM is very useful as a debugger, but it takes a bit of thought Several common possibilities for "sporadic" and "never never land": 1) Are your MODA and MODB pins tied low? BDM only works reliably if the chip starts in Special Single Chip mode. You code (or your debugger) can change the mode after reset, but you need to start in Special Single Chip so that the micro doesn't take off and start executing until you tell it to. 2) Does your code enable the COP? It is disabled when you come up in Special Single Chip. However, if you enable it and don't service it, a reset will occur (duh). However, during this reset, the BGND line will probably NOT be low, so the chip will start in NORMAL Single Chip mode rather then Special Single Chip. So, BDM won't be enabled, and since you got a reset, all your hardware breakpoints are gone. 3) I haven't used CodeWarrior, but if your code moves the I/O register block, the hardware breakpoints move with it. Will CodeWarrior know where to find them? 4) If CodeWarrior uses the BDM TRACE1 command for single-step (as opposed to using automatic breakpoints), please be aware that if there is an interrupt pending (and there usually is if your program has been stopped in the debugger), TRACE1 will trace into the interrupt routine - after all, it is just tracing the "next instruction". Are you just that "never never" isn't an interrupt routine? 5) Are you enabling the PLL? Some 9S12 chips (at least the the Axxx and Dxxx) have a bug that messes up BDM when you enable the PLL. Most debuggers have a work-around, but you may need to enable it. Best regards, John Hartman NoICE Debugging Tools http://www.noicedebugger.com |
Reply by ●April 24, 20042004-04-24
|
Here's the answers to your questions: 1) MODA and MODB are tied low. 2) I'm not enabling COP. 3) I don't think they are moving the I/O block. 4) ??? 5) Yes I'm enabling the PLL. I have a timer interrupt enabled that it jumps to repeatedly when single stepping. I was able to stop this behavior by setting the TSFRZ bit in TSCR1. I'm using the parallel port BDM and I see that there is a appnote regarding the fact that some parallel ports may not be able to drive the BDM without cutting a pin on a resistor network on the BDM. I was running the BDM using a pass-thru on another device so I connected directly to the parallel port and it is working a little better now but still jumps off and executes 'BGND" instructions when single stepping. Also when this is happening, I'm seeing the message "Frequency change detected, reconnect using io_delay_cnt: "2" " in the command window. I have a USB BDM at my disposal also so I tried this also. It works 100% better but still jumps off and executes the "BGND" instructions no and then. What are these? Now I have another problem that's very perplexing. I have a function declared as: void SPIMEMWrite(unsigned long Addr, byte *pBuf, unsigned long Len); I make a call like: SPIMEMWrite(0L, &Buffer[0], 16L); I put a breakpoint just inside the function and the arguments are not correct. Addr = 1048592 // incorrect pBuf // correct Len = 1048592 // incorrect Any ideas? ----- Original Message ----- From: John Hartman (NoICE) To: Sent: Friday, April 23, 2004 4:18 PM Subject: Re: [68HC12] BDM problems >I'm fairly new to using the HC12. The tools I'm using is CodeWarrior >and the Multilink BDM. The BDM doesn't seem to be working correctly >as a debugging tool. Breakpoints only seem to work sporadically and >when I try to single step the processor seems to jump off into never, >never land. Am I doing something wrong or is the BDM pretty useless >as a debugger? Any ideas? BDM is very useful as a debugger, but it takes a bit of thought Several common possibilities for "sporadic" and "never never land": 1) Are your MODA and MODB pins tied low? BDM only works reliably if the chip starts in Special Single Chip mode. You code (or your debugger) can change the mode after reset, but you need to start in Special Single Chip so that the micro doesn't take off and start executing until you tell it to. 2) Does your code enable the COP? It is disabled when you come up in Special Single Chip. However, if you enable it and don't service it, a reset will occur (duh). However, during this reset, the BGND line will probably NOT be low, so the chip will start in NORMAL Single Chip mode rather then Special Single Chip. So, BDM won't be enabled, and since you got a reset, all your hardware breakpoints are gone. 3) I haven't used CodeWarrior, but if your code moves the I/O register block, the hardware breakpoints move with it. Will CodeWarrior know where to find them? 4) If CodeWarrior uses the BDM TRACE1 command for single-step (as opposed to using automatic breakpoints), please be aware that if there is an interrupt pending (and there usually is if your program has been stopped in the debugger), TRACE1 will trace into the interrupt routine - after all, it is just tracing the "next instruction". Are you just that "never never" isn't an interrupt routine? 5) Are you enabling the PLL? Some 9S12 chips (at least the the Axxx and Dxxx) have a bug that messes up BDM when you enable the PLL. Most debuggers have a work-around, but you may need to enable it. Best regards, John Hartman NoICE Debugging Tools http://www.noicedebugger.com --------------------To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu o learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu ------ Yahoo! Groups Links a.. To |
|
|
Reply by ●April 26, 20042004-04-26
|
At 07:17 PM 4/24/2004, you wrote: >Here's the answers to your questions: > >1) MODA and MODB are tied low. >2) I'm not enabling COP. Hi Don. Which derivative do you use? An MC9S12T64 would have the COP enabled even in BDM. Which CodeWarrior version for HC12 do you use? >3) I don't think they are moving the I/O block. CodeWarrior Register block moves handling (since V2.0): On MC9S12 derivatives, the target interface automatically tracks (via BDM image) device Registers block moves. For HC12 derivatives, the REGBLKADR command can be used to specify the new location of the register block. >4) ??? While stepping in the debugger, if there is a pending ISR, the next step dives in the ISR. This can be avoided masking maskable interrupts. To do this, simply click on the I bit in the Register window to set/clear this bit. In latest CodeWarrior for HC(S)12 v3.1 : It is possible to disable maskable interrupts while stepping, when checking the "Disable maskable ISR's when stepping" checkbox in "Communication"|"Special Setup" dialog. This option will also care about possible operations performed by the current instruction vs. the I bit. >5) Yes I'm enabling the PLL. > >I have a timer interrupt enabled that it jumps to repeatedly >when single stepping. I was able to stop this behavior by >setting the TSFRZ bit in TSCR1. Yes, definitely a good way to freeze the timer while debugging and avoiding falling in timer ISR's, and forgetting point "4)" here above. >I'm using the parallel port BDM and I see that there is a appnote >regarding the fact that some parallel ports may not be able >to drive the BDM without cutting a pin on a resistor network >on the BDM. I was running the BDM using a pass-thru on >another device so I connected directly to the parallel port and >it is working a little better now but still jumps off and executes >'BGND" instructions when single stepping. Also when this is >happening, I'm seeing the message "Frequency change detected, >reconnect using io_delay_cnt: "2" " in the command window. If your OS is Windows XP, have a look on http://www.pemicro.com. The "WINXP2.REG Utility" might be useful for the parallel cable. >I have a USB BDM at my disposal also so I tried this also. It works 100% >better but still jumps off and executes the "BGND" instructions >no and then. What are these? It is not obvious that at this point, the cable reads correct data from the chip. The debugger might returns bad info. Correct that "Frequency change detected..." is displayed in the Command window when the PLL got engaged. But io_delay_cnt: "2" means that the chip bus frequency is around 33 MHz, rather fast for a bus speed max of 25 MHz (specs). Could you give more details about the Xtal/oscillator you use and your PLL registers setup? Does your code change the PLL only once after reset or several time? Did you check the "Set CLKSW bit in BDM control register (MC9S12 only)" option in the ICD-12 menu, Connect.../Communication dialog? Regard, Gilles >Now I have another problem that's very perplexing. I have a function >declared as: > >void SPIMEMWrite(unsigned long Addr, byte *pBuf, unsigned long Len); > >I make a call like: > >SPIMEMWrite(0L, &Buffer[0], 16L); > >I put a breakpoint just inside the function and the arguments are not correct. > >Addr = 1048592 // incorrect >pBuf // correct >Len = 1048592 // incorrect > >Any ideas? > > ----- Original Message ----- > From: John Hartman (NoICE) > To: > Sent: Friday, April 23, 2004 4:18 PM > Subject: Re: [68HC12] BDM problems > > >I'm fairly new to using the HC12. The tools I'm using is CodeWarrior > >and the Multilink BDM. The BDM doesn't seem to be working correctly > >as a debugging tool. Breakpoints only seem to work sporadically and > >when I try to single step the processor seems to jump off into never, > >never land. Am I doing something wrong or is the BDM pretty useless > >as a debugger? Any ideas? > > BDM is very useful as a debugger, but it takes a bit of thought > > Several common possibilities for "sporadic" and "never never land": > > 1) Are your MODA and MODB pins tied low? BDM only works reliably if the > chip starts in Special Single Chip mode. You code (or your debugger) can > change the mode after reset, but you need to start in Special Single Chip > so that the micro doesn't take off and start executing until you tell > it to. > > 2) Does your code enable the COP? It is disabled when you come up in > Special Single Chip. However, if you enable it and don't service it, a > reset will occur (duh). However, during this reset, the BGND line will > probably NOT be low, so the chip will start in NORMAL Single Chip mode > rather then Special Single Chip. So, BDM won't be enabled, and since you > got a reset, all your hardware breakpoints are gone. > > 3) I haven't used CodeWarrior, but if your code moves the I/O register > block, the hardware breakpoints move with it. Will CodeWarrior know where > to find them? > > 4) If CodeWarrior uses the BDM TRACE1 command for single-step (as opposed > to using automatic breakpoints), please be aware that if there is an > interrupt pending (and there usually is if your program has been > stopped in > the debugger), TRACE1 will trace into the interrupt routine - after > all, it > is just tracing the "next instruction". Are you just that "never never" > isn't an interrupt routine? > > 5) Are you enabling the PLL? Some 9S12 chips (at least the the Axxx and > Dxxx) have a bug that messes up BDM when you enable the PLL. Most > debuggers have a work-around, but you may need to enable it. > > Best regards, John Hartman > > NoICE Debugging Tools > http://www.noicedebugger.com > > --------------------To learn more > about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > o learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > > >------ > Yahoo! Groups Links > > a.. To >--------------------To learn more >about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu >o learn more about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu > >Yahoo! Groups Links > > |
|
|
Reply by ●April 28, 20042004-04-28
|
Hello Gilles Does CodeWarrior for HC(S)12 v3.1 work with existing Version 3.0 licenses, or does one need to buy an upgrade? Many thanks! Robert On Apr 26, 2004, at 9:58 AM, Gilles Blanquin wrote: > In latest CodeWarrior for HC(S)12 v3.1 : It is possible to disable > maskable > interrupts while stepping, when checking the "Disable maskable ISR's > when > stepping" checkbox in "Communication"|"Special Setup" dialog. This > option > will also care about possible operations performed by the current > instruction vs. the I bit. |
|
|
