Andreas Daetwyler

access problems to target with  USB P&E and MC9S12XDP512

Discussion created by Andreas Daetwyler on May 4, 2007
Latest reply on May 21, 2007 by Andreas Daetwyler
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).


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!!! :smileymad:
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?