Cannot program MSP430F135 rev AE with MSP430-PRGS

There is no difference between those silicon revisions regarding the JTAG interface. The MSP-PRGS430 device should be able to program the latest rev. as well.

I don't know which version of the MSP-PRGS430 software your customer is using, but they can try to install the latest MSP-PRGS430 Software (Rev. I).

Important:  please make sure that the JTAG interface circuit on your customer's design is according to the recommended JTAG connection shown in Figure 3-5 at page 43 in the MSP430 Family Serial Programming Adapter (Rev. H)

BR,

Mo.

The customer is using the latest software--rev 1.32, but this only supports device revs through AA.  It doesn't recognize rev AE.

I'm trying to find out if there's a newer release, or if one is planned.

I don't think that the Software will make any difference between the silicon revisions. As you can see it in the F135 device erratasheet (http://www.ti.com/lit/er/slaz017e/slaz017e.pdf) the only difference is in the BSL version which has nothing to do with the JTAG interface.

What is the exact error message your customer get when trying to program the F135?

BR,

Mo.

I agree this should have nothing to do with BSL.  The problem is with the programmer recognizing the AE device.   Here is the error message they get:

MSP430F135 Reset --> Wrong target!

 

Mo. said:

the only difference is in the BSL version

There's another difference: the part ID. It is possible that the new revision is simply unknown to the programmer because of its different ID.
The programmer needs to exacly identify the MSP it is attached to. This includes the silicon revision. If the firmware/software is older than the silicon revision, the chip won't be recognized. It could be a s well a completely different JTAG device.

Jens-Michael Gross said:

There's another difference: the part ID.

I am not sure what you mean by part ID. Do you mean the Chip ID that is located at address 0FF0h ? As far as I know the Chip ID is not device specific, but device Family specific. I have just checked SLAU319B and there the Chip ID for the F135 part is F149h.

I'm not sure what the programmer is reading to determine the specific device, but I suspect this is the problem!  Somehow it recognizes the different device revisions.  For example, this is from the release notes:

New Features and Bugfixes

Version 1.32

• Added Revisison AA for F14x 14x1 13x and 13x1.

The firmware for the programmer was updated in the past to include new part revisions, and it looks like that is what is needed now.   Are there any plans by TI to update this?  The last update was in 2010. 

Mo. said:

Do you mean the Chip ID that is located at address 0FF0h

I don't think this value from the BSL area is used to identify the MSP udner JTAG control.

For the 54xx devices, the TLV structure holds Device ID (which is 0x54xx, depending on the chip), followed by hardware and software revision. I have no clue where the older devices withou TLV structure store this information, but it most likely goes beyond  a simple family ID. If you select a 169 as target device and try to program a 1611, you'll get an immediate error that the device doesn't match. The family ID might be sufficient for the BSL, but for JTAG, detailed information about device and hardware revision is required. And the FET will only accept devices whcih it can detect based on its internal table. Newer silicon revisions aren't in this table. The FET then doesn't kow how to control the device porperly (type and features of the EEM etc.) and therefore rejects the device as unknown.

That's at least the exceprt from various older threads I've read in the past. It's not the first time this happens.

Jens-Michael Gross said:

I don't think this value from the BSL area is used to identify the MSP udner JTAG control.

Maybe this is true. However, I have just checked the MSP430 Programming Via the JTAG Interface (Rev. D) at page 54 in Table 1-14  you can find same information.

Mo. said:

I have just checked the MSP430 Programming Via the JTAG Interface (Rev. D) at page 54 in Table 1-14  you can find same information.

This document is about the replicator hardware that doe snothing more than reading or writing a firmware as a stand-alone solution.

This replicator does not provide debugging capabilities, so it might be sufficient to know the flash controller type in the target and nothing more.

The FET, however, uses high-level functions split into the PC MSP430.DLL and the FET firmware. Maybe not the FET firmware needs an update but the MSP430 LIB (which in turn will usually update the FET).
The PC software jsut calls an 'identify target' funciton and gets back either an exact identification or an 'device unknown or not attached' error. And the exact identification includes the silicon revision. Without this information, neither debugger nor FET will be able to properly program the EMM, apply workarounds to EMM or JTAG-related errata etc. If you just want to read or write flash through JTAG, dies all might not be necessary, but on the FET it either works all or nothing. There is no 'you may be able to program but not to debug this device' option.

Who is in charge of support for this programmer?  All the discussion on what used by JTAG isn't that helpful, since I don't have source code for the programmer.  This is not the standard FET tool, but the old MSP430-PRGS.  

I need to know if we plan to update this for the newer devices, or if there's a way to patch it.

The device info appears to come from the device.cfg file that's part of the software.  Here's an example entry

[MSP430F135_A]
DeviceName= MSP430F135
DeviceID = 0xA40B6301A40BFDF75628DCFFF89754235467956CDC424173

Hendrix said:

[MSP430F135_A]
DeviceName= MSP430F135
DeviceID = 0xA40B6301A40BFDF75628DCFFF89754235467956CDC424173

This looks promising. IF there is an [MSP430F135_B] or _AA section, maybe you can figure out how to write an entry for your chip revision. Maybe it's just one or two bytes that follow a pattern (or you find this pattern on the AA chips and can read the proper value sfor the newer revision with a FET that already supports it)

Jens-Michael Gross said:

I don't think this value from the BSL area is used to identify the MSP udner JTAG control.

Actually it does. Also, while the PRGS430 is an obsolete design where we don't add support for new devices the case under discussion here is clearly something that needs to be updated and fixed. I'll let our tools team know immediately so that we can get a fix on the way. I'll provide an ETA once I get feedback.

Andreas

This is to inform that the PRGS430 tool folder has been updated with a new device.cfg file that addresses the MSP430F13x/F14x-related issues under discussion. The web page also contains instructions on how to apply the update to an existing installation of the PRGS430 software.

http://www.ti.com/tool/msp-prgs430

Thanks and Regards,
Andreas