P&E Multilink

Started by Adrian Vos October 25, 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
> 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
> 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