• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 2618 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FG4619: Same hex file - different memory from three different parts.

David James97
Prodigy 20 points
Part Number: MSP430FG4619
Other Parts Discussed in Thread: UNIFLASH,

I have created a release hex file for the board that we have designed.  To ensure that we are programming the MSP430FG4619 with the proper executable, we are calculating a checksum over the program space.  With the same hex file and using the UniFlash programmer set to erase main, information, and protected memory, I am getting a different checksum from three different parts.  I know that I am not modifying the executable as I have added debug code to break if the checksum computed at the end of my main loop differs from the power up checksum.  The power up checksum is reported via message.  I have pulled the memory off the parts and diff'ed them.  The memory is off in 1 byte near the end of the executable (~80 bytes before the fill), but still within the executable.  1) I am confused as to why this would be happening.  2) I am confused as to why my executable seems to run correctly if there is a different byte in the program space.

Any help or explanations would be greatly appreciated.

  • 0
    TI__Mastermind 49692 points

    Hi David,

    When you erase the INFO memory, are you making sure that the TLV and other important calibration values are preserved? If you'd perform a checksum across the entire memory of the device and these values have been preserved, it makes sense that the checksum would be different, since these values are unique for each device. I've read that setting software breakpoints can cause a checksum difference. Is there a way that you can rule out that the debug session is causing this to occur? Perhaps, instead of outputting a message, you could blink an LED or toggle a GPIO without an active debug session.

    Regards,

    James

    MSP Customer Applications

  • 0 in reply to James Evans
    Prodigy 20 points
    James,

    The debug code was added code, not using the debugger (not an active debug session). The address range over which I am attempting to calculate a checksum is 0x2100 to 0xFFC0. The method to "send a message" is a serial message to another device.

    DJ
  • 0 in reply to David James97
    TI__Mastermind 49692 points
    Thanks for the clarification. Looking at Table 6-4 Memory Organization in the datasheet, the Interrupt Vector is located in Main Memory between addresses 0xFFC0 to 0xFFFF. If you're including the first byte of the Interrupt Vector in your checksum calculation, this may be why the results are different, since different interrupts would be set at different times across the devices. Can you try checking the checksum from 0x2100 to 0xFFBF?

    Regards,

    James

    MSP Customer Applications
  • 0 in reply to David James97
    TI__Mastermind 49692 points
    Hello,

    I'm closing this thread due to inactivity. If you have a new question, please start a new thread.

    Regards,

    James

    MSP Customer Applications

**Attention** This is a public forum