Target request failed: Failed to step / Failed to Run-to-line / Failed to resume

[cab]

CW10.2(1.0.0) MC9S08LG32 Win7x64

Debug is stopped.  All I can do is Terminate, it appears.  This happens too often.  Does anybody know how to recover, or how to avoid?

-Cab-

[BlackNight]

Hello,

did you receive any more information/diagnostics?

I recommend to enable 'enable logging' in the P&E debugger connection for MCU10:

http://mcuoneclipse.wordpress.com/2012/02/23/an-error-occurred-applied-debugging-rules

This will write diagnostic information to the Eclipse console view.

Additionally overlapping flash memory in the application might cause that (in)famous 'Failed to resume' message, see http://mcuoneclipse.wordpress.com/2012/03/30/problem-occurred-flash-programming-with-overlapping-mem...

Hope this helps,

BK

[cab]

BK-

I will try 'enable logging' and get back to this post.   This is not just a  random occurrence with my CW 10.2.  I can hardly get any stepping done on one MCU (so I use a lot of print-statements :smileyhappy:.  Bad enough that I tried installing 10.2 on an XP, but the symptoms were the same.  Bad enough that I am considering using 6.3 on that XP for this project, hoping it will accept my project and the Multilink that I have for this MC9S08 MCU.  But I expect that the modules that control the debug are so numerous and low-level that they will be the same between 6.3 and 10.2.

-Cab-

[cab]

BK-

I was not able to find the connection-panel with the [x]enable-logging checkbox you display in your blog: an-error-occured-applied-debugging-rules. I searched mightily, perhaps not smartly.

It appears that I had a faulty P&E Multilink (USB-ML-12E).  It started giving me continuous Power-Cycle dialogs--tho I didn't know the cause (naturally I blamed CW10.2, or possibly my own hardware :smileyhappy:.  I was dead-in-the-water yesterday--it always failed.  Since I replaced the Multilink, debugging, stepping, running-to-line, etc. have performed up to original expectations.  I expect that the fault has existed ever since I have been using 10.2 and this particular ML (a few months)--because I have always suffered that problem with 10.2--and didn't know it was supposed to work this well.

The reason I am boring people with the above, is to ask: if I -had- enabled logging--could it have alerted me to a hardware problem with the Multilink?  If you have time to point me to the connection-panel, I am anxious to use it.

(I will close this problem after I am sure the ML fixed it.)

Thanks greatly for your assistances.

-Cab-

[BlackNight]

Hi Cab,

the 'Enable Logging' option is in the connection settings page of the run/debug configuration. In MCU10.2 go to the debug configuration (menu Run > Debug Configurations), select the configuration on the left hand side, and then press the 'Edit...' button on the connection.

See attached screenshot.

BK

[cab]

BK-

That's not so hard to see--sorry I didn't.

Thanks for your patience.

-Cab-

[cab]

BK-

I have had some isolated failed to step/run-to-line/resume with my new probe--but my experience has been remarkably better.

• Just now I had the problem and looked at my console logfile--I don't see anything that would help mefind the cause, but I have attached it.  I note that there are no time stamps, even periodic ones. 
  I copied the logfile as soon as I got the failed-to-step error, which was shortly after the other two
  .
• The only entry I canfind that looks relevant isfairly close to the bottom:
  
  GDI: DiMemoryRead(addr = 0x8333, space = 1, mem_items = 8, size = 1)
  GDI: => DI_OK
  GDI: 0F14273201093E01
  GDI: DiExecSingleStep(instr_no = 1)
  GDI: => DI_OK
  GDI: DiRegisterRead(PC (id:0x0))
  GDI: => DI_OK
  .
• I see no DiExecRunToLine or DiExecResume's.  And I can't tell if instr_no=1 means good or bad.  The details in the error message was something like "maybe you previously had a breakpoin there and so that is why you are seeing this failure" but that is far fetched I think.
• Occasional fails I can put up with--tho sometimes a step-over becomes a step-in and I have to step thru every line of code
  
  I know you are a busy person and can't take the time to peruse every logfile.  I'll keep the console logging and let you know if I find anything that looks relevant when the debug machinery fails again

Thanks.

-Cab-

[BlackNight · Accepted solution]

Hi Cab,

I have not spotted anything particular in your log file. I think in your case that would not helped much.

As for the faulty Multilink: I had a case where the ribbon cable was partly broken at the connector (bending it too many times at the connector had broken the copper wires inside the cable :smileysad:

And I had a case where the USB soldering points for the USB connector were bad after long usage.

Do you know what is the problem of your multilink?

Glad to see that you are up and running again (at least with the different Multilink),

BK

[cab]

BK-

My Multilink was also broken at the connector.  I knew about that but it was intermittent so I thought the Multilink hardware was the cause of the power cycles.  It turned out that once the cable was repaired my old one worked fine.  That was good.  But the new cable often can't step, run, or resume too often and sometimes all at the same time.

Thanks for looking at my logfile.  I've never spotted anything interesting either.   Is it the case that you (and others) hardly ever have a problem resuming, stepping, running to line?  I don't see any me-too's on this post,  Perhaps it is a combination of CW 10.2 and Win7x64.  But I did try 10.2 on an XP machine, seemed to have about the same performance.  I'd hate to think that CW is picking ion me--what did I ever do to it? (Except complain a lot).

I appreciate your resourcefulness..

-Cab-

[BlackNight]

Hi Cab,

no, I have not had many problems with breakpoints and stepping.

A few things to consider:

- limit the number of breakpoints. The hardware only has a few hardware breakpoints, and having more than the limit (usually 2-3) on at the same time is not a good thing. To view the current number of breakpoints, open the Breakpoints view. I usually clean up / disable breakpoints I do not need any more, and usually only have 2-3 active at a time. Note that the debugger needs breakpoints for stepping as well (temporary breakpoints).

- The other case I had problems with breakpoints was when the power supply to the board was not good enough. In one case my wall power converter was the problem (exchanging it solved the debugging problem). In another case my board was powered through USB from a notebook: the notebook was not able to deliver enough current. Powering the board with a high current wall mounted USB power supply solved that problem for me.

Hope this helps,

BK

[cab]

Thanks, BK-

Hmm! No big problem with stepping, etc.  Do you often use an HC9S08?  Or with CW 10.2 Win7x64?  I'm trying to find something about my project that is unusual--else I'm just the proverbial sad sack. 

I am careful about too many breakpoints--my first project was an MC68HC908LJ12 and I think it had only one--which is why I would be happy with only run-to-line.  I don't think my breakpoints are hit reliably anyway, even with only one, so I often check the breakpoints, delete them all and add only one. Now, the project is so mature -- I mean most everything work--that I no longer use the debugger--just download (with Run Configurations :smileyhappy:, remove the probe, and hit the power button.  I find that the probe definitely affects the IIC communications.  I have one master and 8 slaves--all HC9S08's.  Upon power up, the first thing the master needs to do is count his live slaves by looking for an IIC response from each one..  Well, I only have 1 slave MCU on the board so far, so 7 are always dead.  The 8th is dead about 50% of the time if I leave the download connector in--even passively, I mean not connected.  Never dead when disconnected.

Getting the IIC to work was a struggle, so the debugger was part of the problem--but not having -any- idea what the slave was doing when I was stepping through the master IIC code was another.  So I now see that I should have asked for -two- probes--since the slaves have no other I/O than the IIC bus.  I don't know if CW10.2 accepts two probes so that two MCU's can be debugged at the same time--but if it doesn't, I could always use two laptops--very cheap solution compared to debug time. 

Thanks for your helpfulness.

-Cab-