Completely lost and can't get the debugger/simulator to work! PBMCUSLK

[Cory]

I am very new to freescale and I am trying to simulate a very simple project onto my board. My board has the model: PBMCUSLK

The project completes the "Make" sequence, but when
we try "Debug" then the simulator freezes for
several minutes and the following error messages
appear in this order:

HI-WAVE
Failed to find communication speed!
OK

HI-WAVE

Communications with target failed:
The target MCU has no clock or wrong BDM clock
speed is used or derivative is secured.
Press the YES button if you want to try to unsecure
right now.

IMPORTANT: Unsecuring will mass erase the device!

Yes No

(After choosing Yes...)

Unsecure derivative
In order to check the derivative status (secured or
unsecured), the value of the IO_DELAY_COUNT is
needed to connect to the target.

for CABLE12: 16 /

for CABLE12HS, MULTILINK, CYCLONE PRO:
( 200 / oscillator frequency in Mhz ) - 1

for USB 2.0 MULTILINK (rev. B):
( 240 / oscillator frequency in Mhz ) - 1

IO_DELAY_COUNT: [enter value here]

Okay Cancel Help

(At this point we have no idea what it is talking
about so we have tried a few different numbers)

Information required to unsecure the device
To unsecure the device, the command script needs
the correct value for ECLKDIV/FCLKDIV onchip
registers.
If the bus frequency is less than 10 MHz, the value

tho store in ECLKDIV/FCLKDIV is equal to:
"bus frequency (kHz) / 175"

If the bus frequency is higher than 10 MHz, the

value to store in ECLKDIV/FCLKDIV is equal to:
" bus frequency (kHz) / 1400 + 64"
(+64 (0x40) is to set PRDIV8 flag)

Datasheet proposed values:

bus frequency E/FLCLKDIV value (decimal)

16 Mhz 73
8 Mhz 39
4 Mhz 19
2 Mhz 9
1 Mhz 4

CLKDIV: [enter value here|default 73]

(We just keep on clicking OK)

HI-WAVE

Derivative could NOT be unsecured!!!!
The Unsecure command file might be missing or
disabled.
Make sure the command file defined in the Unsecure
panel of the Command File dialog contains the
correct commands to unsecure the current connected
derivative and the board oscillator frequency.

OK

At this point it freezes for a while again than
starts the error process over again.


Does anybody know how to solve this problem? Thank you, in advance, for your help!

Added PBMCUSLK to subject.

Message Edited by NLFSJ on 2009-02-11 09:20 AM

[qty154]

Hello!

I have got the same problem.

I have a flexray kit (EVB9S12XF512E) and one board works while the other is dead. The system chip keeps on rewsetting the CPU so I removed the J27 jumper.

However, I cannot connect it with the PE USB multilink BDM debugger, I get the same error message.

I looked at the CPU clock, that seems to be OK.

I see no difference between the two boards.

There is no way to stop it with the debugger, after a reset command the board becomes a runaway. No way to unsecure it, either.

I use CW5.1.

I remember that I did some BDM script for the MPC555 to reset and stop that when that board ran uncontrolled. Is there a similar script available for this target also?

Thanks for the help

Attila

[qty154]

Hi again!

I don't know what I did, but now I managed to render both cards unusable.

The PE BDM seems to be the 'guilty' one as others like the coldfire and hc08 folk complained about the same problem.

I just wonder what Motorola is doing. Selling an EVB kit with a tool suite that doesn't run the attached demo program because of 32 file license limit, attaches a PE debug interface that renders the cards unusable, PE wants to make money by not providing but only selling the prog12z tool which may be the salvation, and Motorola keeps quiet. I looked all over the internet without finding any one happy customer that solved this problem.

The MPC555 support was much better, where is Randy now?

Back to the symptoms, the PE will download an applet (info applet) to 0x2000, but it cannot overwrite what is already there. There is seemingly useful stuff at 0x2000 ( not zeroes ) so the part is neither secured nor protected.

I edited the applet S-records in the .fpp file so that it actually downloads only a couple of zeroes where there are only zeroes already, then it doesn't complain any more, but still not able to flash the part.

Could someone please be a useful help on this issue?

Best regards

Attila

[qty154]

Hello all who are intrested,

that I solved this problem by downloading the PE unsecure utility that at last unlocked the part.

Why the attached unlock script in the debugger doesn't do this I don't know.

Best regards

Attila

[Lundin]

PBUMCUCLK seems to come in the following flavours:

PBS08QG8SLK (HCS08)
PBS12C128SLK (HCS12)
PBS12DT256SLK (HCS12)
PBS12XDT512SLK (S12X)
PB56F801SLK (DSP)
PB5211SLK (Coldfire)
PB52233SLK (Coldfire)

Without knowing which CPU you are targeting, it isn't possible to answer the questions. Since you posted in the 8-bit forum I'll assume HCS08.

The problem is that the debugger can't find the mcu. This can be caused by many things.

First check the the board is alive and has power. Then use an oscilloscope to verify that the reset pin is stable (high) and that the oscillator is running on the correct frequency. If there is no external oscillator active, the HCS08 will run on an internal oscillator (I don't remember the frequency on that one, check the manual). Then check that the BDM is connected properly and not upside-down.

When you have gone through all of the above, then there is a reason to suspect that the MCU is secured and you will have to unsecure it as you tried to do through the debugger.

You will have to select which BDM pod you are using. If you are using HCS08 and a BDM from PE Micro, this will either be PE USB Multilink or PE Cyclone Pro. The oscillator frequency you should be able to obtain from the oscilloscope and/or the data sheet in case of the internal oscillator.

The FCLKDIV stuff you shouldn't need to concern yourself with, the program should understand these things once you have the correct frequency. PE pods should be able to auto-search for frequency, so you shouldn't need to do this... which makes me think that the problem is hardware-related.

[bigmac]

Hello,

Are you using the correct version of Code Warrior to suit the MCU device?

Regards,
Mac

[Cory]

Yes. If I plug in an identical board and debug it works just fine.

[J2MEJediMaster]

Compare both boards closely. Do any of the jumpers differ?

---Tom

[Cory]

Ah hah! You were right, one of the jumpers was set incorrectly! Thank heavens the problem is solved!