MSP430G2553: MCU ID Codes for G2553 (vs FR2475) --- looking for clarification on the address to read device ID and what constants to expect

TI Friends and Family,

Our customer has found a peculiar anomaly between ID Codes on FR2475 and targeted G2553.  Comments welcomed!

[Customer}

I am getting our manufacturing line ready for FRAM parts.  Recently we realized we would like to track, in our manufacturing database, for each widget made, what was the mcu.  In our plan, a mix of parts can arrive at the program/test station and the program needs to seamlessly handle all.  

We’ve learned that the FRAM MSP430FR2475 gives us a mcu id at address 0x1a04.  In my program I can now read that address through the JTAG and figure out that I am dealing with MSP430FR2475 or something else – thus my program handles FRAM and FLASH smoothly.   

But for the other value series we use, 2475, 2402, 2553, we don’t know what address might have those codes and what the codes are. 

 So right now the best I can do is save a Boolean to the database – FRAM yes/no.  But I’d really like to know for sure which specific MCU I have, for a more meaningful record. 

 So my question is, is there a TI document that lists the “Information” addresses of all MSP430 that contain this mcu code and what the codes are?

[TI]

There is a table found in “MSP430 Programming with the JTAG Interface” www.ti.com/lit/pdf/slau320 [ti.com] section 2.6 “JTAG features across device families”, that lists the device ID address and value for different devices. There are a few tables in this section as for the Flash vs the FRAM families there are different locations that this is found. The JTAG tool actually reads the device ID before programming so it can use the right memory map, JTAG features, etc for that part – so usually in CCS or other program you are using with your programmer, it knows what device you have set it up to be trying to access and then it checks that when it reads this address it gets the expected value for that device ID and will throw a warning if it does not match.

 The TLV in INFO A is a bit different – on the Gxx parts that is stored in user-accessible flash and could be erased – it contains calibration info, but not the device ID because the device ID needs to be somewhere that it cannot be accidentally erased (since it is used by JTAG etc and you need to always be able to access/recover the part).

[Customer]

I finally tried the Elprotronic instruction F_Get_Device_Info() today.  Turns out it doesn’t do what I thought.  Prior to configuring the device per what we know to be the device ID, that command just produces the same garbage text no matter what MCU is attached.  Documentation says “Desired index processor should be first set in the configuration …).

 I did some playing around with MSP430G2553, and the table Katie referred to.  I must be missing something.

 According to https://www.ti.com/lit/ug/slau320aj/slau320aj.pdf [ti.com], I should be able to read two bytes at 0x0ff0 and 0x0ff1 and get the code 0x2553:

 But, according to the datasheet,

 The memory map shows that 0x0ff0 and 0x0ff1 is not addressable memory. I’ve tried to read those bytes and the Elprotronic F_Memory_Read_Data()  function returns a fail status code.

 I am guessing I might find a Device ID in the Information memory, but the datasheet doesn’t supply a map of that except for segment A.  But the apparent conflict between the two documents is puzzling.

[TI/Elprotronic]

It is possible to read any MCU location  but first it must be connected with MCU using Open Target Device funcion. If response is correct tben Read memory from specified address should reply. We can connect via M.Team in the next week and check what is done not orrrectly in your side, or email me sequence functions you are using then we can check it now.

[Customer]

I am looking for clarification on the address to read device ID and what constants to expect.  The MCU we use in all our products are MSP430G2553, MSP430G2402, MSP430G2475.  Address 0x0ff0:1 does not work.

 We wish to improve this: get the device ID correctly and reliably for both.  We have other processors to handle in the future, and data is going into a database.

COMMENTS AGAIN WELCOMED!

TY,
CY