• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 293 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP-GANG: Does the programmer verify that the microcontroller matches the one that the image was created for?

Mark Regina
Prodigy 130 points
Part Number: MSP-GANG
Other Parts Discussed in Thread: MSP430G2402, , MSP430G2232

During this seemingly unending semiconductor shortage, I needed to change the microcontroller on an existing PCBA to one that was actually available to purchase.  Ended up replacing an MSP430G2402 with an MSP430G2232.  Our CM failed to notify me when the change occured in our scheduled deliveries of boards, and the received PCBA's weren't marked with the new revision, so our manufacturing line unknowingly used revised boards.  We use an MSP-GANG programmer to program eight identical boards at once.  The programmer successfully programmed the boards built with the MSP430G2232 even though the image was built for an MSP430G2402.  I thought that the MSP-GANG would ID the microcontroller first and if there was a mismatch between the image and the one detected, that it would signal an error -- IT DIDN'T.  Is this normal operation for the programmer?

  • 0
    Guru 33653 points

    Don't know what type of image file is used, but for typical ti txt / hex format binaries, info about target device is not stored inside file.

  • 0 in reply to zrno soli
    Prodigy 130 points

    When run in standalone mode, the "image" that is used by an MSP-GANG contains more than the code file (ti-txt).  It contains which programming port(s) to use; whether the programming interface is JTAG, SBW, or BSL; selection of the source of power for the target; and more.  More info can be found at:  https://www.ti.com/tool/download/MSP-GANG-SOFTWARE

  • 0
    Prodigy 130 points

    Another quirk is that the ti-txt code file for the MSP430G2402 fills the full 4K even though under 2K is all that is really used (filled with 0x3FFF which will force WDT to expire if it ever happens to wander into the unknown) and the MSP430G2232 has only 2K of code space.  Does this extra 2K of code get sent to the microcontroller?  And if it does, how does the microcontroller deal with out of bounds addressing?

    MSP-GANG's firmware rev is 1.02.09.00

  • +1 in reply to Mark Regina
    Guru 33653 points

    If G2402 is replaced with G2232, and device ID is stored inside special MSP-GANG type binary image, than you can see in slau320 that both devices belong to G2xx2 and have same ID (Device ID at 0x0FF0) 0x24 and (Device ID at 0x0FF1) 0x52. I don't know if there is something special inside MSP-GANG used for device ID recognition, but for TI MSP430 DDL this (G2232 and G2402) are identical devices regarding flashing.

  • 0 in reply to zrno soli
    Prodigy 130 points

    Thanks for the JTAG users guide reference -- it has the information on why the programmer will program the code file into any member of the family to which the desired device belongs.  For my case, this makes it easier, since I do not need to have extra images loaded on the programmer.  One image will correctly program the family members that have the necessary minimum code space and all of the needed peripherals.

    The ability to program 4K of code into 2K is probably due to the final 2K of the 4K being 0x3FFF and during the verify stage, 0x3FFF is most likely returned for addresses that are not physically present -- no verify error.  This would also mean that the state machine(?) inside the IC that handles programming also does not throw an error for out of range addresses (silicon for this may be identical for all family members?).  I could test this by editing the ti-txt file to have 0x3FFE in any one location in the final 2K, rebuilding the programmer image, and seeing if the programmer detects an error during verify.

    EDIT:  0xFFFF would most likely be read back for out of range addresses, so it should fail the verify!

**Attention** This is a public forum