severe problem upgrading to MSP430.DLLv3

I had the same problem yesterday... I had a perfectly functional IAR 5.10 environment.  Upgrading to 5.40.2 and then SP5.40.3 has rendered my FET/Board/Debugger a useless toolchain.

The FET tool is v1.4, and it now lights Power solid green on plug-in (as expected with the new firmware), and the COM port shows up on the device manager as "MSP-FET430UIF - CDC (COM5)" properly

Upon trying to debug, the emulator warns: Emulator: Fatal Error: Failed to initialize, Check if hardware is connected, Check if drivers are installed, Try to restart the computer, Tools using the parallel port are not supported on Windows Vista

I'm running the USB FET on Win7 64 bit.  I've tried "automatic" and "COM5" in the FET Debugger Setup of IAR.  It's not just CCS or your cable length.

Unfortunately, I don't have a solution yet... but there sure are a lot of frustrated posts on E2E.

You can downgroad it again, you know that right?

There is already a tool nistalled with the CCS ( TI Software). I dont know how to do it with the IAR Workbench, but i guess there is a stand alone downgrader available in the msp430debugger wiki somewhere.

At least my version works properly when using DLLv2 again. Sadly I cannot use CCS5.1 with the old DLLv2.

All:

What device are you using?

You may be running into a known issue with our CCSv5.1 and v3 DLL bug affecting some of our silicon devices. The issue is that the v3 DLL would not work on some devices depending on the revisions of the die. It has affected several MSP430F4xx and some 5xx devices also. This issue has been resolved and will be released as part of the CCSv5.2.

As of now, the DLL patch for CCSv5.1 can be found here:

e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/155784.aspx

Regards,

William

Hello,

hm this at leasts seemed like a reason. I am currently working with the MSP430F2274 and the MSP430F5437A.

MSP430F2274: I had 3 modules, 2 were not working with CCS5.1 but 1 was working just fine with CS5.1.

MSP430F5437A: I have like 10 PCBs to test on the end of the week, right now I can debug 2 of them, because more I didnt solder yet. But with this device there doesnt seem to be any problem, till now.

So perhaps this really could be a die issue. Exactly i am using the MSP430F2274IRHAT ( 40RHA -package ) perhaps there is also an issue? I obviously cannot know that.

seb,

I just did a quick test on my bench here with the same exact package for MSP430F2274 with CCSv5.1 and CCSv5.1.1 and I couldn't reproduce this.

What's the silicon revision that you have for the F2274? I want to see if I can hunt down the exact revision.

Did you give the DLL patch a quick try?

Another possibility is to double check your capacitance on your reset line. There is a strict capacitance value that needs to be there for it to properly function under debug and download mode, see SLAU278. If you temporarily remove the capacitor, does it still exhibit the same behavior? Somehow maybe v3 DLL may have exacerbated some timing behavior that wasn't an issue in v2 DLL.

Regards,

William

Thanks for your effort.

Unfortunatly I cannot test the modules any more, we already sent them out, as we had a timeline to hold.

But with those modules it wasnt that critical, as they are only for a mechanical test, so it is not important whether the MSP430 is working properly or doing anything at all. That is why I did the switch to CCS5.1 right now, because the critical modules I had done weeks ago with the older CCS4.2xx.

As I always expect something bad happening when changing or updating some development tool :) I did when nothing serious can happen to our products.

So I cannot test your patch, nor the capacitance.

But again: The Hardware and Software is the same in DLLv2 and DLLv3, and ist working and debugging correctly in DLLv2 but not in DLLv3

I do program over a acable length of around 1,5m; so I guess a change in baudrate in the DLLs could cause some problems in my case.

As I do have other PCBs with MSP430 on it and all of them work properly with short cables and the new DLLv3, I kind of narrowed the problem down.

Where can I see what silicon revision I have? Is it printed on the MSP?

MSP430

F2274

TI G16I

A644 G4

If that does help. We did order the whole populated PCB, so without calling our "populator" ( the company that does produce our PCBs and populates them) I cannot tell what silicon revision MSP430F2274 they ordered, as I only gave type and package to them.

Seb,

It looks like this QFN packaging does not have the revision on the package. The only way to read it is by connecting to the device and read the TLV memory. Aside from that, I would prefer to check if the new DLL works first.

William

Here is some follow-up that others may find helpful:

Although the driver appeared to be installed correctly in Device Manager->Port view, IAR's IDE had no control over it.  In the Options->Debugger->FET Debugger setup->"...", when picking a port for the USB connection, there is a note that says "To identify a connection, click on a port in the list to see the Mode LED on the attached USB-IF light up".  Clicking on ports gave no response

In an attempt to brainwash my setup and start over, I unplugged my FET, uninstalled all of my previous IAR 430 installations (4.21, 5.1, 5.4), tried to uninstall "DriverX for MSP-FET430UIF" but it never uninstalled properly after several attempts, and then installed 5.40.2 and SP5.40.3.

After doing that, IAR was able to make the Mode LED blink on the FET, and it could program my part properly when running at 2.8V.  Unfortunately, it still reported a problem communicating with the MSP when running at 1.8V.

Putting a scope on the SBW signals showed that the SBW data line barely transitioned fast enough to meet the clock edges at 2.8V and outright failed to meet the timing at 1.8V.  Changing the capacitor on the RST/SBW data line from the recommended 2200pF to 1000pF brought the signal transitions back before the clock transitions, and the part programs fine.

Did anything on the SBW timing change with the upgrade to the CDC driver and FET firmware?  I'm admittedly running ~11" cable between FET and PCB (the guidance is 8"), but these signals were really gross.

Thanks for the suggestions to downgrade, but given a project in the latest IAR, it's not possible to use an older IAR compiler and older FET firmware/drivers. I did try, just to use the FET on an old project, but the downgrade utility failed several times before I gave up and brainwashed the system as described above.