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.

CCS upgrade breaks UIF firmware which fixes connection issues but confounds developer

Other Parts Discussed in Thread: MSP430F6736

For MSP430F6736 development I have been sailing along with CCS 5.3.0.  Recently lost ability to flash a test board and figured I had somehow bricked the CPU.  So set that aside and moved on. 

Meanwhile had to install CCS on laptop for remote work and therefore downloaded CCS.  Attaching the MSP430 UIF (same one used in the 5.3.0 environment) I got dreaded message about firmware update.  There was absolutely NO explanation given that the firmware in the UIF was associated with CCS 5.3 and - more importantly - that the version of CCS is one that's later than the firmware on the UIF!  If CCS can tell the firmware version on the UIF, surely it can tell me more?

After considerable worry, I went ahead with the firmware update.  Worry because I have already bricked my first UIF on the first day I received it, so naturally was worried.  But it worked.

Here's what's puzzling:  the old board I thought had a bad CPU was now able to connect and debug through the UIF.  So something got updated in the firmware that fixed an old problem?

I am working with 2 wire SPI which the UIF still does not automatically detect and form which CCS does not provide an option to select. These facilities seem basic to me, and I had told TI about this some time ago, but apparently it's still not fixed. 

I had to use a trick that took weeks to discover in the beginning of my work with these tools - using the FET Pro 430 tool to select 2 wire SPI mode.  Once done, it is retained in the UIF, and things work. 

In today's case I tried this and got a message from the FET Pro 430 tool that the firmware needed to be upgraded.  But.. I just got finished upgrading it!  So I was not about to do this again.  I ignored the message and things worked fine.

Returning to home base and CCS 5.3, CCS also complains that the firmware needs updating.  I ignore this message and things also work fine.

Quite bizzarre and worrying for lack of a stable development environment suggests that my production code may have troubles introduced by same.  Hopefully not.

Now, some questions:

1. Is there a way to tell CCS 5.3 that the latest firmware for the UIF is already loaded so it does not remind me each time?

2. What changes or bug fixes might account for the surprised but welcome restored communications to my target board?

3. When CCS is installed why doesn't it tell you the version and provide a change log?  (I had to do a deep search on TI to find it, finally).

4. Should I update my workstation development environment to CCS 5.4?  Seems reasonable, but I am worried that other things will break.

  • Mark Richards1 said:
    1. Is there a way to tell CCS 5.3 that the latest firmware for the UIF is already loaded so it does not remind me each time?

    CCS doesn't track the "latest" firmware version of the UIF. What happens is that the MSP430.dll used by CCS (and FET Pro430) contains FET firmware with the same version number as reported by the MSP430.dll. If the firmware version in the UIF is different to that in the MSP430.dll then CCS (or FET Pro430) will ask you if you want to "update" the firmware. Where MSP430.dll updates are made to support new devices, as well as for bug fixes.

    Depending upon how updates are applied to CCS and FET Pro430, the MSP430.dll versions used by the programs may be different and therefore moving use of the same UIF between the programs can cause messages about "updating" the firmware. The only way I have found of stopping these reminders to make sure all the programs are using the same MSP430.dll version.

    Mark Richards1 said:
    2. What changes or bug fixes might account for the surprised but welcome restored communications to my target board?

    Looking at the revisions.txt in the MSP430.dll 3.3.1.003 available at MSP debug stack nothing stands out as explaining a bug fix for your MSP430F6736 (although some of the bug fix descriptions are a bit vague).
    Mark Richards1 said:
    3. When CCS is installed why doesn't it tell you the version and provide a change log?  (I had to do a deep search on TI to find it, finally).
    Thats a good point - CCS if quite happy to offer updates without an obvious explanation of what the update contains. Probably worth a separate thread on the CCS forum.
    Mark Richards1 said:
    4. Should I update my workstation development environment to CCS 5.4?  Seems reasonable, but I am worried that other things will break.
    Installing CCS 5.4 in a new directory should be safe, and allow switching between CCS 5.3 and 5.4 as required. On a XP machine found that CCS 5.3 had a habit of locking-up when first loaded the workspace, which is no longer present with CCS 5.4.

  • Mark Richards1 said:
    I am working with 2 wire SPI which the UIF still does not automatically detect and form which CCS does not provide an option to select. These facilities seem basic to me, and I had told TI about this some time ago, but apparently it's still not fixed.

    I did see a CCS enhancement request to add an option for CCS to select JTAG / Spy By Wire / Automatic selection - should be in CCS 5.5.

  • CCS doesn't track the "latest" firmware version of the UIF.

    It would be helpful if a difference is flagged only if the UIF firmware is older than the firmware that the DLL defines and CCS expects to see.  If there are no regression issues, newer firmware should work fine.. ??

    Installing CCS 5.4 in a new directory should be safe, and allow switching between CCS 5.3 and 5.4 as required. On a XP machine found that CCS 5.3 had a habit of locking-up when first loaded the workspace, which is no longer present with CCS 5.4.

    I tried installing to the existing first and it failed.  Indeed, installing to a new directory worked and left the old one in good shape. 

  • Chester Gillon said:
    If the firmware version in the UIF is different to that in the MSP430.dll then CCS (or FET Pro430) will ask you if you want to "update" the firmware.

    Indeed the message about 'update' is a bit misleading, because it well may be a 'downdate'.
    Due to space limitation and timing requirements, the FET firmware doesn't provide backwards compatibility with previous MSP430DLL versions. Nor does the MSP430DLL contain fallback for older firmware versions. It is pure luck if two different versions work with each other. If they do, there's no need for an update even if it is recommended over and over again. It is well possible that everythign works except for e.g. a certain debugging feature, and one will never notice the incompatibility. And sometimes, the changes are indeed compatible, but the updating mechanism doesn't know this.

    Chester Gillon said:
    Looking at the revisions.txt in the MSP430.dll 3.3.1.003 available at MSP debug stack nothing stands out as explaining a bug fix for your MSP430F6736

    Perhaps soem changes in the timing. Maybe the MSP contains an offending firmware that crashes/resets the CPU and sewers the JTAG connection. And with the new firmware, the JTAG connection is established a little bit faster and the FET can interrupt an MSP before it loses the connection again due to the reset. Or the SBW timing has been improved and is now more stable when the connected hardware is at the edge of the specs (line capacitance or resistance etc.)
    Sometimes such things are not even intended but happen coincidentally. Nobody checks foe positive side-effects. QC usually just checks whether things were broken by an update.

**Attention** This is a public forum