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:

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:

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:

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.

As this produces a lot output, I configure the Console View using the menu Window > Preferences not to limit the 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 🙂