Summary of issues with CW, P&E BDM debugger & Cyclone Pro

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Summary of issues with CW, P&E BDM debugger & Cyclone Pro

4,260 Views
Wings
Contributor I
After this post I guess I'll quit posting about my issues with CodeWarrior's IDE. It's strange that I've not had one reply from anyone using this configuration for code development. Surely I'm not the only one taking this route. But anyway, after days of toiling with this thing, here is a summary of what's stopping me from making any headway. I get identical results from two systems, one running XP Home and the other XP Pro.
--------------------
1. In a fresh debugging session, with no breakpoints, continuously hitting Start/Cont and Halt results in the command window stating that "Frequency change to ~xxxxxx." every time the target is halted, where xxxx alternates between approx 4MHz and 8MHz. Eventually there is a pause and then all target registers are filled with ones, even the PC ($FFFF). The only way to recover is to reset the target system which kills the debugging session you are in. This issue pretty much renders the debugger useless.

2. Placing 3 breakpoints (not at consecutive instructions) works, until the 2nd one is removed and another one is placed prior to the 1st one. After that, what was the 1st breakpoint is never executed although the debugger still has the breakpoint marker (red arrow) showing at that location in the Source window. (This is probably the 2nd most serious issue, since it can and would lead to erroneous conclusions when debugging code!)

3. Placing 2 breakpoints at 2 consecutive instructions does not work. The second is skipped, and after hitting the Start button several times a dialog pops up saying the BP could not be set. Then, once both are removed the second stays active even though it is not marked as active (red arrow) in the Source window. Resetting the target system does not correct this. Quitting & restarting the debugger does.

4. Although only 3 breakpoints are allowed, the debugger gladly allows setting more than 3. Only when the code is run are you told that the debugger could not set a breakpoint (doesn't say why). After removing the 4th breakpoint and hitting Start/Cont button one or more times, the system pauses then stops with the message in the command window "Trigger A & B occurred", even though no such trigger conditions had been set. Furthermore, the target system is shown with all ones in every register, even the PC ($FFFF). The only way to recover is to reset the target system which kills the debugging session you are in.

5. Setting a trigger address A in the Data window causes a halt when the address is accessed, as expected, but no trace data appears in the Trace window. Setting a trigger address B in the Data window works (memory read/write data does appear in the Trace window).

6. Right-clicking on the Memory window brings up the pop-up menu, but the menu does not contain any options to choose triggers (as shown in Freescale app note AN2596). Trigger options DO appear when right-clicking the Data window. This used to work but after an hour or so of using the debugger it no longer does, even after a power down / power up of everything.

7. When starting a new debugging session the debugger cannot find the CyclonePro, and gives the suggestion to unplug the usb cable temporarily and try again. This works but is becoming quite annoying.... it should remember how it found the Cyclone from the last run.

8. When entering the debugger after a recompile, the debugger runs my target program automatically. I cannot find the option to make this not happen.
Labels (1)
0 Kudos
4 Replies

459 Views
UK_CF_FAE
NXP Employee
NXP Employee
Hi Wings,
 
I sorry that you are having trouble with CW and no-one has responded to your plea for help. You should certainly take Rocky's advice and post it to a service request at www.freescale.com/support
 
When you do that, please mention to the TIC which Target Setting you are using. This should be a P&E Target Interface and not the (more obvious, but wrong) BDM_HCS08 target interface.
 
Mark
0 Kudos

459 Views
Wings
Contributor I
Thanks for the response guys. I did exactly as you have suggested yesterday (would have done it sooner but it was the weekend). Spent hours on the phone with engineers at FS. They could replicate all the issues I am seeing, but this morning I finally got to the root of issue #1 (Run-Halt-Run-Halt = "Trigger A & B occurred"). Thank goodness it was me.

The COP timer was causing a reset. The test code wasn't disabling the COP nor was it servicing the COP. Shoulda seen that from day one, since I am quite familiar with the COP and use it all the time. But it does reveal that CW isn't handling a target reset very gracefully.

I discovered this when running my real application code. It didn't experience the problem since it did the right thing with the COP, and that took me to discovering the fault with the test code.

Issues 2, 3, 4, etc. have been referred to the CW-IDE group, and when I hear anything from them I'll post their response here.
0 Kudos

459 Views
UK_CF_FAE
NXP Employee
NXP Employee
This CW 5.0 project is set up to run with DEMOS08QG8 and is what I use to demonstrate some of the more complex features of the BDM module. I've set up breakpoints, markpoints, complex triggers and used the trace with it.
 
I use the USB MultiLink for the demos, but it will work with the Cyclone Pro.
 
Mark
0 Kudos

459 Views
RockyRoad
Contributor III

Wings -

This is the point where this needs to get escalated beyond the forum and go into the Service Request System.

I have confirmed the problem with breakpoints on two consecutive instructions both on the QG8 and on an RG60. I also found that the QG8 didn't seem to work right with the two breakpoints separated by a NOP.

I couldn't get either of your RUN/HALT cases to fail, but that's on my setup. (I didn't see the bus frequency change as you saw.)

I haven't gotten to test any others at this point.

You have a very good and clear write up of your issues. You should include that in a Service Request and let the system report the bugs to right people on the CodeWarrior team. 

- Rocky

0 Kudos