AN2295, CFV1, MCGTRM, and P&E Multilink debugger

[dougpaulsen]

It's difficult to know exactly where to put this query, but here is the problem:  I'm successfully implemented the fabled AN2295 bootloader in a MCF51AC256 project.  I should be satisfied with that, but I found that if I interrupted the bootload while in progress, the AN2295 code would not allow the process to restart following a reset button closure. 

Of course I tried to debug the AN2295 code (it's amazingly compact assembly language - not my current forte) via CW6.3 and a venerable P&E USB Multilink BDM version C debugger, but the debugger consistently looses contact with the target when the code loads the MCGTRM register.  In fact, to get the bootloader to work, the debugger must be disconnected from the target.  Understand, the code works and works well, but without the debugger, it is a burn 'n learn development process.  Did I mention I am going to need to expand the bootloader (currently serial) to accommodate a different input source?  I can't see that happening without the debugger being in the picture.

Does anyone have any experience or thoughts regarding debugging the AN2295 MCF51 bootloader?

Thanks!

[TomE]

Note I've never used an MCF51-anything. I'm just reading the manuals and going from experience with other chips.

> P&E USB Multilink BDM version C

Make sure it has the "clock" jumper inside it set properly.  Rumour has it it has to be set to "NO CLK" for most devices. I think I remember it only ises "with clk" for some very old CPUs. Check this on P&E's site or google it.

> debugger consistently looses contact with the target when the code loads the MCGTRM register.

If there's a loose contact you just have to tighten it up (sorry :-).

With what value from what value? The Manual says it defaults to 0x80 when run from the debugger, which is different from the normal operation where it loads that register from a Factory location.

Check that it is loaded with 0x80 as expected. Then try loading it with the same value and see if you LOSE the connection. If that's OK, try changing it by "1" then "2" and so on. There may be a maximum change value that you can use to retain control. Then change the code to stay under that value, or maybe change it in small steps.

What value is the code loading into MCGTRM? It may be getting a zero or all-ones value from somewhere. It may be reading the "Factory" trim location and you may not have that programmed or set properly when running under the debugger.

You can always write a "debug version" of the bootloader that you only run under the debugger that avoids doing problematic things. Once you've got your new code working you revert to "normal" run mode. You could also write a boot version that checks some registers to find if it us running under the debugger and behaves differently. You may find you need to debug the loader in "external crystal" mode on a development board if that is possible.

If you can't step THROUGH the code that loads MCGTRM can you set a breakpoint after that point and RUN through it?

Tom

[dougpaulsen]

Hi Tom:

Thanks for your response. Indeed, the Freescale bootloader was retrieving

MCGTRM from 0x3FF. My code hadn't used that space to store a value so it

was retrieving default 0xFF, definitely NOT the 0x80 value the debugger

needs to run (that's a footnote in the user's manual, if you know to ask).

I can debug the bootloader now, but I'm still having trouble getting to

recover from a previous interrupted bootload (my original problem). More

challenges!

Doug

On Wed, Jul 2, 2014 at 10:28 PM, Tom Evans <admin@community.freescale.com>

[TomE]

> More challenges!

Watch out for the COP. Some of the more complicated chips have an option to STOP the watchdog when you're single-stepping the code.

Not this one. SOPT and SOPT2 are WRITE-ONCE registers, so your boot can either enable (forever) or disable (forever) the watchdog. So it makes debugging your watchdog handling tricky.

Tom