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 / MSPFET430UIF problems: MSP430: "Trouble Halting Target CPU: Could not terminate EEM polling thread" et. al.

I have been experiencing frequent reliability problems with using CCS and the MSPFET430UIF in SBW connection mode to a target which is a MSP430F2012IN device which is connected to the FET via something very close to the recommended SBW JTAG mode interface circuit diagram.

The custom target board is self powered in all cases, not powered by the FET, and the appropriate jumper settings to connect VCC target to the FET (as recommended by TI) are followed.

There is no capacitor connected to the target's RST line, so the 2.2nF maximum capacitance on the line is not violated by the target board design.  I am using both the 14 pin JTAG cable and USB cable included with the FET, and they are in good condition.

I am using CCS 4.20RC1, microcontroller core edition, running under Windows 7 either 32 bit or 64 bit, and it was installed with UAC disabled as recommended.

The JTAG SBW connection of the target is very similar to the recommended design here, but with no added capacitor on the RST line:

http://processors.wiki.ti.com/index.php/JTAG_%28MSP430%29

 

The most common error I see in conjunction with CCS/FET operation is a failure of the FET/CCS to connect to and control the target for the usual debugging operations -- reload program, halt target, restart target, reset target CPU, et. al.  A common error message appearing in the CCS console for this situation is: "MSP430: Trouble Halting Target CPU: Could not terminate EEM polling thread." which is repeated one or more times as I try various CCS menu options to control the target.  Typically it will take several unsuccessful manual attempts (to the point of time out and command failure) to communicate with the target before occasionally any control is regained.  Most often, however, I'll need to do something like physically unplug the FET from the target SBW and maybe the PC USB and reconnect it before I can regain CCS control of the target.  Often I'll have to exit and restart CCS in order to get it to be functional and responsive.  Indeed often (typically after a few such target communication failures / timeouts) CCS itself will either lock up (become unresponsive to the GUI in ways besides failure to control the target debug state) or CCS will crash and exit spontaneously.  Fairly often I'll have to use Windows Task Manager to manually end the java process corresponding to CCS's runtime before I can successfully exit a non responsive CCS and restart CCS.

My typical debug process is:

1) Target is initially powered off. 2) SBW JTAG cable is disconnected from the FET.  3) FET is connected to the PC USB 4) CCS is launched.  5) JTAG SBW cable is connected to the target board.  6) Target is powered on via its local power supply/switch.  7) A project is modified / rebuilt using CCS.  8) A debug session is launched using CCS and the new program is loaded via the "Reload program" menu/dialog using CCS.  9) "Target: Run" is used in CCS to run the target program.  10) The target's operation is tested for a few minutes.  11) The project source code is modified in CCS, and the project is rebuilt.  12) The "reload program" option is used to attempt to halt the running target and load the new program onto the target.  13) "Target:Run" is used in CCS to run the target program, as in step #9, and the following steps are repeated through a few iterations of test / debug / modify / recompile / reload / run.

Very often no more than 3x or 4x times through the above process past step 9 is required to cause the FET/CCS to have a problem being able to successfully reload a modified program, and at that point it is not likely that I'll be able to "Halt" or "Restart" or "Reset CPU" successfully either from CCS control, and I will have seen one or more error messages and time outs such as "Trouble Halting Target CPU: Could not terminate EEM polling thread" at this point.

When I leave the FET connected to the PC and the FET SBW JTAG connected to the target, but I power cycle the target, it generally does not seem to help cause CCS to regain communications / control of the target, and I don't recall seeing any status messages concerning the target being power cycled or whatever.

When I unplug the SBW JTAG cable from the FET and then reconnect it while the target is powered up, that sometimes lets CCS/FET communicate again with the target, but often it does not help.

In the worst case but still happening fairly often, after a couple of failed communication attempts with the target, CCS itself will either become unresponsive or will crash and exit, and restarting CCS possibly after manually killing any remaining java process task is required to regain functionality.

My questions are as follows:

A -- I do not recall seeing any explicit guidelines about the USB FET's operation with respect to plugging an "in use"/live FET into either a powered off (and not FET powered) target, or plugging a live FET into live target board, or unplugging a live FET from a live target, or power cycling a non FET powered target while the live FET is attached.  I assume these are "ok" scenarios typical of various debugging usages, but in case there are particular warnings against one or more of these scenarios, I'd be glad to know of them.  In my case the FET is getting the target's self made Vcc sent to it as recommended, and I am not doing anything besides CCS defaults to select a compatible FET operating voltage level with respect to the 3.3VDC target's local power supply.

My concerns are simply that ideally CCS and the FET could manifest some more reliable sort of way to more quickly and robustly connect to or reconnect to a target if for some reason the SBW communications are interrupted.   Ideally my hope is for a relatively robust and immediate response to the "reload program" or "reset CPU" commands.  Certainly I'd at least want to see CCS itself not crash or become unresponsive in such cases, though of course I understand this is just a RC1 build, and that it may not be as polished as the final version.  I seem to recall having similar issues with 4.1.3, though, and also others have previously reported very similar issues with past CCS versions e.g.:

http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/18552.aspx

I seem to recall seeing some message about a new model USB FET being in the works.  From using the existing model, one suggestion that I'd find handy would be some physical buttons on the FET to initiate a target RESET, and also a switch to select whether the target will "free run" upon the target being power cycled versus whether it will be under FET debug control if the FET SBW JTAG is connected and CCS is running.

Anyway it is not such a big deal, but I thought I'd mention the issues in case it would help the development/QA process of CCS to identify and improve some of these issues for forthcoming versions.

Thanks,

Chris

 

  • I think it may be worthwhile for you to try KickStart -- not as an alternative to CCS, but only to verify that the problems are caused by CCS.

    I had problems with KickStart too, But they are not the same as what you described.

  • OCY, Thanks for the suggestion.  I hadn't really thought about the possible debugging benefits of switching tool sets, but you're right, it would be interesting to see if it behaves better / differently with the alternative tool chain.  It might be easier to automate the tool chain install / upgrade / compile / reload processes with the lighter weight / smaller  kickstart tool set as well.  I'll give it a try.

     

**Attention** This is a public forum