M5213EVB and P&E Debug

[ColdFireHot]

When using the M5213EVB with CLKMOD[0] tied to ground I get an error trying to debug.

Does anyone know if I need to change some configuration file in CW6.3 or is this a hardware issue?

I am trying to get a MCF5211 in a 64 pin package to operate correctly with the debugger.  Since this part has CLKMOD[1] pulled low internally I need to understand what is needed to get it up and running.

Thanks,

Mark

[mpeters]

You said that when CLKMOD1 is pulled to ground (meaning the jumper is installed), you have errors debugging. What are the errors? And, more importantly, what is the CLKMOD1 signal doing. Is it high or low (jumper not installed or installed)? You'll need to also position the CLK_SEL jumpers accordingly. My guess is that you have the CLKMOD0 jumper installed, but the CLK_SEL jumpers 1 and 2 are still installed. This is not a valid configuration option and needs to be changed. There is a silkscreen table on the back of the board with all of the valid clock configuration options. If you have a configuration other than these options, you won't be able to debug as the processor won't be getting a valid clock.

As for the MCF5211, by pulling the CLKMOD1 signal low internally, we're setting the PLL to be disabled out of reset. This can then be overwritten in your code, giving you full PLL functionality. Then, depending on how you pull the CLKMOD0 and XTAL signals, you can use a crystal oscillator to supply the clock to the MCF5211, a canned oscillator, or you can run it off the internal oscillator. For more information, please refer to chapter 6 of the MCF5213 reference manual. Here is the link:
http://www.freescale.com/files/32bit/doc/ref_manual/MCF5213RM.pdf

Regards,
mpeters

[ColdFireHot]

Here is an email exchange I had with Axiom concerning this issue.

I have an M5213EVB that I have configured with the CLK1 pin tied low. The goal was to simulate the M5211DEMO board configuration where CLKMOD[1] is internally pulled down.

When I run CW6.3 I cannot get the debugger to work. Is there a configuration file that will write to the processor to configure the processor for debugging?

<Reply from Axiom>

The board should work with CLK1 (CLKMOD1) option in either position (open = high, closed = low). Make sure the BDM_EN option is installed on both pins. Remove the CLK1 option and idle it to return to default configuration. CLK0 should be idle and CLKSEL 1 and 2 ONLY installed.

Note the BDM may issue a Reset unless the cable is configured correctly in codewarrior or the controlling software. The Reset light should be off without BDM installed and power applied if the clock is working.

<Reply>

I started with the default configuration so that when power is supplied the reset light will blink once indicating that the processor is running.

When I install the CLK1 jumper and turn on power the reset light blinks once, again indicating that the processor is running.

This change is the one and only change made.

With the jumper removed i.e. CLKMOD[1:0]=11 then code warrior will run in debug mode loading the program and stepping through the code.

When the jumper is installed i.e. CLKMOD[1:0]=01 then when I run code warrior I get the error "Hardware Diagnostics: PEMicroProtocolPlugin : Can't connect to PEMicro via USB".

According to the MCF5213RM the only thing that changed was the PLL is disabled, not in "Normal" mode. The reset light behaves the same in either case, blinks once when power is applied.

When code warrior enters debug mode successfully the reset light blinks two or three times, however when it fails it blinks once synchronous with the error message.

I have scoped the BDM DSO pin to see if the processor is sending out data, it appear to be, giving another indication that the clock is running.

<Reply from Axiom>

I tried the codewarrior and had the same result. I tried the PE programming tools and the 5213 works ok in both modes. Please report this error to the freescale support for codewarrior and I will do the same.

The PLL disabled mode may be worked around in software if needed, disable the PLL during initialization.

One more thought, the Codewarrior may initialize the target prior to attempting download of code. Please review and see if it is setting PLL frequency and not enabling the PLL first. this may cause the issue. The intialization script should be available in the project or target settings.

Since this conversation I have tried the P&E debugger and programmer with success.  I believe the problem to be with CW6.3.  I have not found a configuration file that would indicate any writes to the PLL settings.

Thanks,

Mark