access problems to target with USB P&E and MC9S12XDP512

[Andi]

Hello, I have a problem when debugging with CW 4.6.

When starting debugging I encountered several strange problems.

First I could load the firmware to the target and debug it - no problems. I could do it several times.

I made a minor change in the source code (adding a new variable) and loaded the target again. Then I could not debug on source level anymore, the cursor always jumped to assembler level to a huge series of BGND instructions. I found out that it jumped into the interrupt service routine in the file Cpu.c (automatically generated for unhandled interrupts).

ISR(Cpu_Interrupt)
{
  asm(BGND);
}

I have no idea what kind of interrupt it could be, in my opinion all interrupts are disabled (all registers INT_CFDATAx are 0).

Ok, I wanted to inspect all the interrupt-related registers to check if I could find out which interrupt was causing it. When I restarted the debugger, I could not access the target anymore!!!
The command window brings the following message (all the time):
BDMSTS BDM register not correct or status mismatch.
A hardware reset might have occured.
Error: The debugger is currently not able to run due to loss of contact with hardware.
FP: McuDesc invalidated.
BDM speed problem

I had exactly the same problem before with another hardware (identical hardware, we have 2 prototypes for debugging). When it happened the first time I thought the hardware is damaged and just wanted to exchange the cpu. But now the same happened with the second board as well! It can't be a hardware error.
I think the problem could be a wrong setting in a register (even though I chose to use the Processor Expert and activated the automatic start-up code generation and variable initialization!)
If the Processor Expert is not worth more than that, I can write the start-up code by myself! It's not possible to unsecure the device and reprogram it - I cannot to anything with the target at the moment. I don't know, if an interrupt in the firmware, that is always triggering, causes the problem. Even if this is the case - it's very bad if you can block the debugger with your own (maybe faulty) application! This should not be the case.

It's the first time for me to work with CW, I think it's a big effort to get a firmware running, I invested several hours, encountering several problems. I think for the price you pay you should get an environment that works a little bit more reliable.

Can anybody give me a hint how I can gain access to the target again?

Andi

[J2MEJediMaster]

It's possible that somehow you accidentally secured the firmware. There are comments in the forum on this happening and how to correct for this. I'll mention one here: If you can start the simulator and it doesn't gripe about connecting to the board, then try using MultilinkCyclonePro menu to issue a Unsecure command. That is : MultilinkCyclonePro | Unsecure... (This menu name wlll be different, depending upon what hardware pod you're using to debug the board with). Now see if you can communicate with the hardware again. Try doing a search on these forums (the search controls are at the lower left part of this web page) for unsecure Flash and similar phrases for more information.

The other thing to check is the clock signals on your prototypes. The error message indicates there might be a BDM speed problem. It's possible (arm waving here, I'll admit) the frequency drifts, and the debugger temporarily works fine. But then the frequency drifts, which causes faulty writes to firmware, which in turn causes all sorts of problems.

---Tom




Message Edited by J2MEJediMaster on 2007-05-04 10:45 AM

[Andi]

I have tried to unsecure the firmware before, as you described here. I cannot gain access to the target - not even to unsecure the target - that's what I was trying to do.

A frequency shift is possible, yes. Just I have no idea what frequency could be set, I think on the 1-wire it's not too easy to measure the target timing with the oscilloscope.

Is there another way to unsecure the target? What do you do if this happens - there must be a way to restore the target, no?

[Alban]

Hello Andi,

Your issue is not CodeWarrior specific, but more a general debugging.
Here are a few tips.

On the BDM, put a jumper between the Background pin and Ground.
This forces the MCU in Special Single Chip Mode (SSCM). And it will output the bus clock on PE4/ECLK.
With an oscilloscope, you can check ECLK to make sure your MCU is not dead.

Once you know the MCU is alive, it is probably only a communication problem between the debugging cable and the MCU.

A first step is to put your oscilloscope on the Background pin. You should see some communication with straight edges and some capacitor-discharge edges.
In both cases, make sure you have pull-up resistors on the both the background and reset pins.
It could be that the communication doesn't start because the cable cannot control the reset.

All of this is to be done once you have ensured that the pin out of the BDM connector is correct.

Alban.

[Andi]

Hi Alban,

thanks a lot for your hints! Indeed I found a hardware error, the Debugger interface could not control the reset line. Now it's working fine, sorry for my complaints.

[CrasyCat]

Hello

Not sure what happens here

You may want to check first if the issue is in the project itself or on the hardware.

Can you create a new project for MC9S12XDP512 from a stationery and try to debug it.

Is it working? If this is working then the issue is probably in your project or project settings.

If this is not working you have a hardware connection issue.

Are you sure the chip is not secured?

I would suggest you to submit a service request to have one of your support engineer looking into that.

Click here to submit a service request.

CrasyCat