Deliberately starting BDM Multilink non-destructive no-code load?

[dkelly]

Am debugging a bootloader which (of course) seems to work perfectly up to and including the moment it resets my HC12. But with BDM attached or not, my CPU doesn't start.

What I'd like to do is attach the BDM to my broken target to sleuth around inside to see what is wrong. Am lost in the multitude of scripts that are launched when the debugger is run from within CodeWarrior.

Is there a simple way to create a no-load debug target that I can go sniffing around in FLASH to see what isn't right? Or launch the Multilink outside of CodeWarrior?

And no, am not setting any of the FLASH security features.

[CrasyCat · Accepted solution]

Hello

It is possible to define a target, which is just connecting to the board and not downloading anything in there.

I assume you are connecting to your board using a P&E MultiLink cable. Am I right?

Create your build target the usual way (just clone an existing target). then apply following changes to the build target:

     - In the "Build Extras" Panel change the Arguments edit box from

       "%targetFilePath -W -Prod=p&e.ini -instance=%currentTargetName"

       into

       "-Prod=hotplug.ini -instance=%currentTargetName"

    - Copy the attached file hotplug.ini to your project directory (where the .mcp file is located).

Following settings will need to be done first time you start the debugger (they will be saved in the .ini file for later debug session).

    - Start the debugger

    - In the connection dialog, specify the Communication device

    - In the Connection dialog go to the "Special setup" tab

    - Check the box "At connection, the target is running (hot plugging)".

    - Select MultilinkCyclonePro -> Set Derivatives" and select the derivative you are currently using.

You should be connected to the chip and you should be able to look at registers, memory, ....

If you want to look at global variable value, you need to do a load symbols from the .abs file (in the Load Executable dialog).

I hope this helps.

CrasyCat

Message Edited by CrasyCat on 2008-07-02 11:02 AM

Message Edited by CrasyCat on 2008-07-02 11:03 AM

[dkelly]

Thats very helpful, altho I haven't worked through it yet.

Yes, the P&E USB Multilink cable, rev C. The red/brownish color version.

What I've found since my original post is that if I launch the debugger from CW when a dialog box appears stating to the effect it is going to interrupt a running program on the target, that if I "cancel" it appears to abort loading a fresh code image and allows me to browse around inside of what was there.

Doing the above I discovered how my vector table was not being written correctly, fixed it, and my new RAM-based bootloader self loaded itself for the first time!

Now the trick is to get our 2 year old bootloader to load the new code, which will then proceed to replace the old. The upper 2k is protected with FPROT = 0xc7. Am being verbose as a means of asking for a sanity check on my approach.

The old bootloader currently replaces everything below 0xf800 correctly (HC12NE64) with my new code. Then it calls 0x40a2 (remember that thread? Thanks!) To debug this I have been using a project with the old bootloader with breakpoint set just prior to the call to 0x40a2. I step into 0x40a2 then "loadsymbols" the .abs file from the binary image the bootloader installed.

Went home last night when it appeared that 0x2000.3fff was no longer RAM after manually resetting in the debugger and directly jumping to 0x40a2 bypassing the old boot code. A fresh start this morning it was obvious I forgot ___INITRG and ___INITRM coming out of RESET.