Reading program memory of MSP430F4250

Hello Ryan,

Thank you for the response. As I understand, if I run this command

MSP430Flasher.exe -n MSP430F4250 -r [output.hex, MAIN]

the firmware should get copied into the computer, which, by running the command given below (where x in COMx stands for port number) can be loaded into the new microcontroller.

MSP430Flasher.exe -n MSP430F4250 -w output.hex -v -z [VCC] (-i COMx) (-e ERASE_ALL)

Kindly confirm.

Aswin,

This depends on whether or not you are concerned about the information memory contents, as written above it is erased without being backed up or replaced.

Regards,
Ryan

Ryan,

1) In the source code, we have not specified any writes to the information memory using the @-operator or the “#pragma location” directives. There are only some #define directives to define constants. I need not be worried about the contents of INFO memory, right?

2) I could successfully read the contents of MAIN, INFO, BSL and RAM memory using MSP430Flasher. Two queries:
a) In our electronics unit there are two identical MSPs with identical firmware. On comparing the two firmwares that was read back using MSPFlasher, I noticed that they are not identical. There are insertions and deletions in the hex files at some locations. Is there any explanation for this?

b) Is there a tool to view the disassembly listing of the hex file that was read from the microcontroller? If yes, that would help me identify the errors in the source code by comparing the disassembly of the (erroneous) source code with that of the hex file.

Thank you.

Aswin,

1) The MSP430F4250's information memory does not store any calibration constants (TLV/device descriptors) so the only concern would be variables that have been directly placed there or your linker file has directed to be stored there. You should confirm this with your map file or by reading the info contents.

2a) This depends on where in the memory you are seeing changes. It could indicate the different status of variables or IFGs that are not handled by the main application at the time the MCU is being read. This only further validates the need for a master binary image instead of copying-and-pasting from another MSP430 device.

2b) No tool is provided, you may be able to use your map file to interpret some commands and the interrupt vector addresses but the rest will be a much more difficult task.

I would focus efforts on recovering the main.c file and creating a new binary image, as several challenges could be encountered by programming devices through this method.

Regards,
Ryan

Ryan,

One of the hex files worked. Thanks a lot!

As and when time permits, we'll try to find the errors in the source code. Thanks again.