Help using USBDM to Debug MCF51JE firmware with no source code

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Help using USBDM to Debug MCF51JE firmware with no source code

762 Views
briandavidson1
Contributor II

ERROR

0 Kudos
3 Replies

728 Views
pgo
Senior Contributor V

Hi,

Assuming you have a working set-up i.e. USBDM software installed and the USBDM interface can detect the target and make a connection.  Test this by running the flash programmer and confirming it can detect the chip.

1) Downloading the current firmware in the processor from the flash if possible (it should be the same but in case it isn't I need a current copy);

The memory dump program can dump the contents of the flash to a file providing the chip is not secured.

2) Evaluating / downloading the contents of the SRAM;

As above but a futile exercise.  The chip would normally be reset when being accessed by the programmer.  The contents of RAM would be essentially random data after reset.

3) Debugging in real time during execution with breakpoints set at various addresses e.g. entry to functions, and stepping along and monitoring registers, stack, etc.

I haven't used Codewarrior for a long time so I can't remember details.  It does provide those features but a limited number of breakpoints depending on the target chip.  I have only used it when debugging a program it is compiling and downloading,  I am unsure if it will allow you to debug from an image.  If working from an image you would obviously only have an bare assembly language view.

4) Recording branches and jumps and register / memory map etc writes and reads, what have you

I don't believe the codewarrior provides tracing.  I am not even sure the chip does either.

If you want help on programming the codewarrior chip or using Codewarrior it would be better to post on the appropriate forum.

For example:

https://community.nxp.com/t5/CodeWarrior/ct-p/codewarrior

https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/bd-p/coldfire

 

bye

717 Views
briandavidson1
Contributor II

ERROR

0 Kudos

699 Views
pgo
Senior Contributor V

Hi,

You are correct in stating that you can usefully read the RAM if you can arrange for the program to execute then connect to the target.  The Memory dump program does not provide that feature but you may be able to juggle connecting to the target to achieve it.  I would only try this if you know there is useful data in the RAM (and it's format of course).

It is more likely that settings are saved in the flash since it claims up to 100,000 program/erase cycles and supports erasing on a sector basis.

The back-door key is a program execution feature.  The sequence must be written by the CPU executing a program already loaded in the chip - not through the debugging interface.  You can't do this if the chip is secured as you do not have the required access.  This is unrelated to the chip flash reprogramming which uses a separate protection mechanism.    This may be moot - is the chip secured?  If the chip is secured (by the image you have) debugging will also be frustrating as it will secure while executing.

Do you have any idea in what language the original program was written in?  For example, working with a disassembled image for a C-program would be very difficult.

What origin is the firmware image you have? Is it an actual program image or is a customised file intended for upgrading the chip?  If the latter it may not be usable for several reasons e.g. encrypted or simple not in a usable format.

Again most of these questions are related to the chip - not USBDM. Try posting on the appropriate forum for more informative answers.  I'm certainly not a expert on Coldfire.

 

bye

 

 

 

 

0 Kudos