“An error occurred…”: Applied Debugging Rules

Yikes! Flashing failed!
All I wanted to do was to re-flash my boot loader on the TWR-LCD board with the ColdFire V1 MCF51JM128 on it. Trying to this gave me a P&E Connection Assistant dialog:

P&E Connection Assistant

P&E Connection Assistant: An error occurred …

The good news is: it shows my P&E Multilink (USB-ML-12) debug cable on USB1. So the cable has been properly enumerated as USB device. And indeed the blue LED on the Multilink is on. But not the orange target power LED :-(. Ahrg, again running into Debugging Rule #1: Check the plug!

Fixing this was easy. Now this brings me one step further. But: now I have a Power Cycle Dialog:

Power Cycle Dialog

Power Cycle Dialog

I power cycled the board, but it is still stuck. Geee, and this really was working yesterday. Checking Debugging Rule #3 Keep an audit did not really help, as I had not changed anything (I swear!).  Clicked away the dialog confirming that I want to abort the connection.

What about the ‘close the eclipse IDE and restart it’ approach? Yes, that is a common approach, and magically that might solve some obscure problems. “Power-on-reset cures everything”. But as this one is about debugger, and here is a dirty trick I have used:  instead of restarting the eclipse IDE, I go into the Windows Task Manager and kill the ‘de.exe‘ process. This is the debugger engine process, and if for whatever reason it has been screwed up, that will definitely help. Needless to say that this did not help in my case. And if it would, I would feel bad about it, as Debugging Rule #4: If you didn’t fix it then it’s not fixed would apply.

Next step would be Holy Water? Not really. Because I missed to check Debugging Rule #5: Stop thinking and look! This rule usually means that you start debugging, but here that rule does not work. Wait, there is one thing:

Problem occurred
Problem occurred

I just had clicked that dialog away instead reading it :-(. The dialog tells me that I was debugging the wrong architecture: everything else, but not a ColdFire V1. And indeed: I was debugging the wrong project with my debug session. Darn, how stupid! I had selected the wrong project in my eclipse workspace!

But at least this is easy to fix. Select the correct project, ensure the correct debug configuration is used, and go! Now flashing the boot loader completed without any further problems :-).

But in case I run into further problems, I apply Debugging Rule #2: Inspect or Report:
I have logging enabled for my all my launch configurations:

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.

Debug/Run configuration with 'Edit...' button to access connection settings

Debug/Run configuration with ‘Edit…’ button to access connection settings

Enable Logging in the Connection Settings

Enable Logging in the Connection Settings

As this produces a lot output, I configure the Console View using the menu Window > Preferences not to limit the output:

Configuring Console View not to limit output

Configuring Console View not to limit output

The Console View gives me a complete picture what is going on:

=== CodeWarrior GDI protocol log ===
GDI DLL: C:\Freescale\CW MCU v10.2\MCU\bin\Plugins\Debugger\protocols\..\..\support\coldfire\gdi\cf_pne_gdi.dll
CPU: MCF52259

GDI: DiGdiOpen()
GDI: => DI_OK
GDI: DiGdiGetFeatures()
GDI: => DI_OK
GDI: DiGdiInitIO()
GDI: Mtwks Callback(MTWKS_CB_COLDFIREAUTOCONFIG, Support: 3, MCUID: 0x8000, Microname: Unknown($8000)) => DI_OK
GDI: Mtwks Callback(MTWKS_CB_SETMEEID, 1) => DI_OK
GDI: Mtwks Callback(MTWKS_CB_PROJECTACCESS, Section : CWDBG, Entry : LaunchConfiguration, Value : Tower, R) => DI_OK
GDI: Mtwks Callback(MTWKS_CB_PROJECTACCESS, Section : COLDFIRE, Entry : ENABLE_FLASH_PROGRAMMING_DIALOG, Value : HFSUIDFH5390FJIfnsdofnfjsdoiFHSIDO, R) => DI_ERR_NONFATAL
GDI: Mtwks Callback(MTWKS_CB_PROJECTACCESS, Section : , Entry : UUID, Value : 8c78db59-73c3-432c-a1c8-dd22465af519, R) => DI_OK
GDI: Mtwks Callback(MTWKS_CB_PROJECTACCESS, Section : STARTUP, Entry : PORT, Value : 1, R) => DI_OK
....
GDI: DiRegisterWrite((reg_no = 0x2008), value = 0x0)
GDI: => DI_OK
GDI: DiRegisterWrite((reg_no = 0x2007), value = 0x40000000)
GDI: => DI_OK
GDI: DiMemoryRead(addr = 0x11600, space = 4, mem_items = 64, size = 4)
GDI: => DI_OK
GDI: 23 C0 20 00 5C C0 20 39 20 00 01 10 22 2E FF F0 4C 00 18 00 70 64 4C 40 18 01 D2 AE FF F4 2D 41
GDI: FF F4 20 2E FF F4 6D 0A 70 00 4E B9 00 01 1F 00 60 12 70 01 4E B9 00 01 1F 00 20 2E FF F4 44 80
GDI: 2D 40 FF F4 20 3C 00 00 FF FF B0 AE FF F4 6C 0A 20 3C 00 00 FF FF 2D 40 FF F4 20 2E FF F4 4E B9
GDI: 00 01 1E 56 4E 5E 4E 75 4E 56 00 00 59 8F 2D 40 FF FC 20 2E FF FC 23 C0 20 00 5C C4 4E 5E 4E 75
GDI: 4E 56 00 00 20 39 20 00 5C C4 4E 5E 4E 75 4E 56 00 00 51 8F 2D 48 FF FC 20 6E FF FC 20 28 00 04
GDI: 2E 80 43 F9 00 01 39 80 41 F9 00 01 39 7C 4E B9 00 00 E3 82 70 00 10 39 20 00 01 00 4A 80 67 1E
GDI: 20 6E FF FC 20 28 00 04 2E 80 43 F9 00 01 39 8C 41 F9 00 01 39 83 4E B9 00 00 E3 82 60 1C 20 6E
GDI: FF FC 20 28 00 04 2E 80 43 F9 00 01 39 91 41 F9 00 01 39 83 4E B9 00 00 E3 82 20 6E FF FC 20 28

This log helped me in the past identifying many issues. As well issues on my end. Things like having accidentally secured and locked the device. But that’s another topic 😉

If you are concerned about this logging impacting your debugging experience and performance: it is not really noticeable for me, so I keep it on all the time. Bu it is easy to switch it off (and again) if needed.

More about debugging rules and a recommended reading: Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems by David J. Agans.

Happy Reading 🙂

Advertisements

9 thoughts on ““An error occurred…”: Applied Debugging Rules

  1. Pingback: Recovering my Chinese OSBDM | MCU on Eclipse

  2. Pingback: Problem Occurred: Flash programming with overlapping memory | MCU on Eclipse

  3. Pingback: Programming part of flash | MCU on Eclipse

  4. Pingback: Dump my Device Memory | MCU on Eclipse

  5. Hi Sir, I tried to debug my software by using the information provided here. But i still having the same error which “the Debugger can not connect to PnE device”

    Do you have any idea why the error is still there ?

    Like

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s