Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Ads
Discussion Groups
See Also
Discussion Groups | 68HC12 | P&E Multilink
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
P&E Multilink - Adrian Vos - Oct 25 3:49:26 2006
Hi All,
Related to my previous query when I was trying to work out what was going
on. The S12DP256B project I am working on has a 4MHz crystal, and uses the
PLL to put the bus speed up to the max 25MHz speed. I use metrowerks to
develop and test code on this platform, and I use the P&E Parallel BDM
Multilink to connect to the target. When I debug my code in the target, I
can step through my code until it reaches the code that enable the PLL at
25MHz, and then it loses control of it.
I originally thought my old parallel multiling could not handle the higher
25MHz clock speed, but I recently got a brand new USB multilink, and it is
having the same problem. This bascially means the only way for me to debug
my code is to run at the lower speed, but sometimes this is not an option,
and it makes it difficult to go back to basic techniques with debugging
variables sent through to a PC via RS232. I would prefer to get the
breakpoints etc. working at the full speed.
Is there anything I can do to maintain control of the target with the hiwave
dubugger with the P&E Multilink over the PLL clock speed change?? Is there a
setting I have wrong somewhere? Can I change my code? Can i change the
firmware in the multilink?
Any help appreciated!!
Cheers,
Adrian
Send instant messages to your online friends http://au.messenger.yahoo.com
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Related to my previous query when I was trying to work out what was going
on. The S12DP256B project I am working on has a 4MHz crystal, and uses the
PLL to put the bus speed up to the max 25MHz speed. I use metrowerks to
develop and test code on this platform, and I use the P&E Parallel BDM
Multilink to connect to the target. When I debug my code in the target, I
can step through my code until it reaches the code that enable the PLL at
25MHz, and then it loses control of it.
I originally thought my old parallel multiling could not handle the higher
25MHz clock speed, but I recently got a brand new USB multilink, and it is
having the same problem. This bascially means the only way for me to debug
my code is to run at the lower speed, but sometimes this is not an option,
and it makes it difficult to go back to basic techniques with debugging
variables sent through to a PC via RS232. I would prefer to get the
breakpoints etc. working at the full speed.
Is there anything I can do to maintain control of the target with the hiwave
dubugger with the P&E Multilink over the PLL clock speed change?? Is there a
setting I have wrong somewhere? Can I change my code? Can i change the
firmware in the multilink?
Any help appreciated!!
Cheers,
Adrian
Send instant messages to your online friends http://au.messenger.yahoo.com
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: P&E Multilink - John Hartman - Oct 25 11:53:33 2006
> From: "Adrian Vos"
> Related to my previous query when I was trying to work out what was going
> on. The S12DP256B project I am working on has a 4MHz crystal, and uses the
> PLL to put the bus speed up to the max 25MHz speed. I use metrowerks to
> develop and test code on this platform, and I use the P&E Parallel BDM
> Multilink to connect to the target. When I debug my code in the target, I
> can step through my code until it reaches the code that enable the PLL at
> 25MHz, and then it loses control of it.
This is due to a known bug in the DP256: enabling the PLL mucks up BDM.
There is an ugly work-around that is supported by many debuggers. It sets the CLKSW bit so that BDM rate follows the CPU rate (rather than the unchanging crystal rate). When the PLL is enabled, the debugger loses communications and either asks you to enter the new speed, or searches for it itself.
Check your debugger docs.
Best regards, John Hartman
j...@noicedebugger.com
NoICE Debugging Tools
http://www.noicedebugger.com
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> Related to my previous query when I was trying to work out what was going
> on. The S12DP256B project I am working on has a 4MHz crystal, and uses the
> PLL to put the bus speed up to the max 25MHz speed. I use metrowerks to
> develop and test code on this platform, and I use the P&E Parallel BDM
> Multilink to connect to the target. When I debug my code in the target, I
> can step through my code until it reaches the code that enable the PLL at
> 25MHz, and then it loses control of it.
This is due to a known bug in the DP256: enabling the PLL mucks up BDM.
There is an ugly work-around that is supported by many debuggers. It sets the CLKSW bit so that BDM rate follows the CPU rate (rather than the unchanging crystal rate). When the PLL is enabled, the debugger loses communications and either asks you to enter the new speed, or searches for it itself.
Check your debugger docs.
Best regards, John Hartman
j...@noicedebugger.com
NoICE Debugging Tools
http://www.noicedebugger.com
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: P&E Multilink - John Hartman - Oct 25 11:59:57 2006
> From: "Adrian Vos"
> Related to my previous query when I was trying to work out what was going
> on. The S12DP256B project I am working on has a 4MHz crystal, and uses the
> PLL to put the bus speed up to the max 25MHz speed. I use metrowerks to
> develop and test code on this platform, and I use the P&E Parallel BDM
> Multilink to connect to the target. When I debug my code in the target, I
> can step through my code until it reaches the code that enable the PLL at
> 25MHz, and then it loses control of it.
This is due to a known bug in the DP256: enabling the PLL mucks up BDM.
There is an ugly work-around that is supported by many debuggers. It sets the CLKSW bit in the the BDM status register so that BDM rate follows the CPU rate (rather than the unchanging crystal rate, which is where the bug is). When the PLL is enabled, the debugger loses communications and either asks you to enter the new speed, or searches for the new rate automatically.
Check your debugger docs.
Best regards, John Hartman
j...@noicedebugger.com
NoICE Debugging Tools
http://www.noicedebugger.com
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> Related to my previous query when I was trying to work out what was going
> on. The S12DP256B project I am working on has a 4MHz crystal, and uses the
> PLL to put the bus speed up to the max 25MHz speed. I use metrowerks to
> develop and test code on this platform, and I use the P&E Parallel BDM
> Multilink to connect to the target. When I debug my code in the target, I
> can step through my code until it reaches the code that enable the PLL at
> 25MHz, and then it loses control of it.
This is due to a known bug in the DP256: enabling the PLL mucks up BDM.
There is an ugly work-around that is supported by many debuggers. It sets the CLKSW bit in the the BDM status register so that BDM rate follows the CPU rate (rather than the unchanging crystal rate, which is where the bug is). When the PLL is enabled, the debugger loses communications and either asks you to enter the new speed, or searches for the new rate automatically.
Check your debugger docs.
Best regards, John Hartman
j...@noicedebugger.com
NoICE Debugging Tools
http://www.noicedebugger.com
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )