MSP430 with CCS:  "Target must be connected before calling the function" - Page 1
Forum section: electronics / general

author: smoothVTer
author_rank: Regular Contributor
timestamp: July 09, 2017, 04:48:39 pm
content: I cannot initiate a debug session between Code Composer Studio v7.2 and an external FR5738; when pressing the debug button in CCS, an error message is displayed GEL: "Target must be connected before calling the function"Has anyone here come across the same error message? I've already thoroughly searched all of TI's MSP430 forum, and tried all the advice posted there with no success on my end. Using CCS v7.2 ( new install from TI download yesterday ) and firmware on programmer gets updated automatically when connecting to my EZ-FET programmer.Here's my setup:Laptop --> USB Cable --> MSP430FR6989 Launchpad. This launchpad contains the EZ-FET programmer, and I have used this same EZ-FET to program a dozen external target processors before using the SBW ( Spy-Bi-Wire ) method in a manner identical to what I describe below. I've removed all jumpers between the EZ-FET and the FR6989 processor on the Launchpad. Using 6" jumpers I then connect:GND on EZ-FET --> GND on my target FR5738 PCBSBWTDIO on EZ-FET --> SBWTDIO on targetSBWTCK on EZ-FET --> SBWTCK on targetSince the FR5738 target is powered on its own isolated 3V supply, I do not connect VCC between the EZ-FET and the target. !RST/SBWTDIO line on target is pulled high to 3V rail via 47k pullup. On the target, I checked all VCC inputs ( read 3V ) , checked VCORE ( read 1.52V ) I ran continuity checks between all connections on the EZ-FET and the target processor's pins, and they all check out. I probed TDIO and TCK on the target pins using a scope as well; when trying to initiate a debug session, and I can see a small burst of activity on clock and data directly on the FR5738 pins. I also replaced the part on the target PCB with another FR5738 from the reel to eliminate the possibility of ESD or a bad part.I tested this setup using a different target, an FR4133, which is mounted on its own Launchpad dev board. Setup and connections are the same; the target is powered via its own isolated supply; I used long 1.5 foot grabber leads for GND, TDIO, TCK lines to stress signal integrity. The FR4133 target is programmed and I can run a debug session fine, leading me to conclude my EZ-FET programmer is operating as expected.for eight hours with no success.

author: alm
author_rank: Super Contributor
timestamp: July 09, 2017, 05:08:18 pm
content: Is using the EZ-FET with an external power supply a supported configuration? TheMSP debuggers user's guidehas the following note:While I imagine they were mostly worried about connecting multiple power sources at the same time, or forward-biasing the ESD protection diodes on the EZ-FET by providing a higher voltage, it does imply that what you are doing is not supported.I wonder if the 3.3 V vs 3 V makes a difference. As far as I know the EZ-FET on the launchpad does not contain target voltage sensing or level shifters, although logic levels between 3.3 V and 3 V should be close enough to work unless the signals were very noisy.Are you sure the MCU on the target board is running (power, clock, etc)? Can you program it some other way?

author: Unknown
author_rank: Unknown
timestamp: July 09, 2017, 05:56:29 pm
content: I have not used the on-board eZ-FET to try and program anything external. However I use the dedicated MSP-FET programming tool and it usually requires a voltage sense line connected to the target's positive rail, so that it can set logic levels on TDIO/TCK. If the voltage sense line is not connected it will act like there is no target.Now the eZ-FET may be a different situation. Since it is mostly used for the target on the same board, it probably always assumes 3.3V. But I thought it was worth mentioning in case there is something similar with the eZ-FET.Is your problematic target running at the same voltage as the eZ-FET? You mentioned 3V, but I don't know if that is enough of a difference to cause a problem. I do see this in the MSP430FR6989 launchpad schematics though:

author: PartialDischarge
author_rank: Super Contributor
timestamp: July 09, 2017, 06:00:20 pm
content: I'll give you the solution:Ditch CCS and the MSP family and move to Psoc Creator.

author: Unknown
author_rank: Unknown
timestamp: July 09, 2017, 06:05:19 pm
content: Quote from: MasterTech on July 09, 2017, 06:00:20 pmSadly you're behind the times. It's time to ditch your PSoC and move to Raspberry Pi. You can implement your code as a Linux Kernel Module written in QBASIC.I swear, I'm not sure whether PSoC is a chip or a religion, anymore...

author: PartialDischarge
author_rank: Super Contributor
timestamp: July 09, 2017, 06:12:14 pm
content: Quote from: Elf on July 09, 2017, 06:05:19 pmYes!!! From now on I will replace my $2-$5 PSoCs with $40 boards!

author: smoothVTer
author_rank: Regular Contributor
timestamp: July 09, 2017, 06:18:21 pm
content: I ran across this same notice, and it did give me pause. So I ran a quick experiment at home to see if it would work again, and it does, but I believe it works for the wrong reasons. Let me explain:The Launchpad on the right is connected to my laptop via USB; all jumpers between EZ-FET and on board processor removed.The FR6989 on the left is is my target. all jumpers removed between the on board EZ-FET and the processor to isolate this MCU. This time I apply 2.0V via an external power supply ( red grabber lead to the "3.3V" pin )Programming and communications are working; I'm running a simple blinking LED test program and see results due to my code changes. However: the voltage rail on the target is ~2.6V, jumping around a bit by 100mV, but external power supply shows 0 mA being drawn. What's happening here is that power is being drawn through the TCK or TDIO lines and the 3.3V from EZ-FET is fighting the local 2.0V supply on the target.I am surprised this is working here with such disparate voltages and a seemingly unstable VCC rail on the target. So the question becomes why this is working here but not on my FR5738 powered from 3V?I may just invest in TI's external programmer which does have rail-sensing capability in the hopes that it'll resolve the communication issue.

author: smoothVTer
author_rank: Regular Contributor
timestamp: July 09, 2017, 06:21:55 pm
content: So do all of TI's MSP-FET dedicated programmers support the 2-wire Spy-Bi-Wire (SBW) protocol?Will CCS recognize a dedicated MSP-FET out of the box?I just ran a part check on digikey, mouser, etc. There is zero stock for part number "MSP-FET" across all distributors, with lead times of 21 weeks?!!! Anyone on here willing to let me buy their MSP-FET to attempt programming with this debugger?

author: Unknown
author_rank: Unknown
timestamp: July 09, 2017, 06:36:08 pm
content: Quote from: smoothVTer on July 09, 2017, 06:18:21 pmHard to say, perhaps the launchpad board has more capacitance than the other target? That can go a long way towards smoothing things out, even to the extent where e.g. Dallas 1-Wire devices can be powered from the serial line.Quote from: smoothVTer on July 09, 2017, 06:21:55 pmI only know about the one currently on the market (TI Store,Octopart, although it seems to be out of stock at the moment?), but for that one, yes on both counts. It just appears in CCS the same way that a Launchpad board does.

author: Unknown
author_rank: Unknown
timestamp: July 09, 2017, 06:45:31 pm
content: Quote from: smoothVTer on July 09, 2017, 06:21:55 pmI noticed that as well, sort of odd. In any case before that, why not try things the other way around? Power the eZ-FET with the same supply as the target.

author: smoothVTer
author_rank: Regular Contributor
timestamp: July 09, 2017, 06:48:30 pm
content: Quote from: Elf on July 09, 2017, 06:45:31 pmYes, that will be my next step on Monday morning when I return to the lab.The target PCB has a TPS63030 converter on it set to 3.0V for the local supply; I'll need to find a way to disconnect this converter's output so that when I apply 3.3V from EZ-FET, it doesn't feed into the converter's output. Thanks for all the help everyone. In the meantime I'm going to try and locate an MSP-FET to buy second hand from the Want-To-Buy forum.

author: alm
author_rank: Super Contributor
timestamp: July 09, 2017, 09:24:43 pm
content: Quote from: smoothVTer on July 09, 2017, 06:18:21 pmThis is very likely due to the protection diodes, There will most likely be diodes from any I/O to Vcc and from ground to any I/O pin, like this:If the I/O goes more than ~0.3 V above Vcc or below ground, then the diodes can become forward-biased and start conducting. This is where the common absolute maximum Vcc + 0.3 V spec for I/O pins come from. I could certainly see this messing up communications, especially with a bi-directional protocol like SBW.It seems weird that it is still working with a 2.0 V target. But you are definitely in the area of not guaranteed specs, so I would not be shocked to see some weird behavior there. Maybe that particular part has a slightly lower forward voltage drop on its diodes or something weird like that.

author: rsjsouza
author_rank: Super Contributor
timestamp: July 10, 2017, 02:58:12 pm
content: Quote from: smoothVTer on July 09, 2017, 04:48:39 pmI vaguely recall something similar happening to me; it was due to a power supply glitch that was triggered during the debug session launch. CCS did all the prechecks (voltage, signaling, etc.) but, during the process of actually connecting to the core and loading code, the power supply dipped a bit and CCS got disconnected.Quote from: smoothVTer on July 09, 2017, 06:18:21 pmAs alm mentioned, these ultra low power micros usually draw power from anywhere - I used to have trouble performing Energy Trace measures on these devices as not all the power (in this case in the order of hundreds of nA/few uA) was being supplied by the power supply directly but from other sources.Quote from: smoothVTer on July 09, 2017, 06:18:21 pmJust adding to other's comments, I suspect the FR57x is a bit older than FR69x that may well marginally draw higher power and thus kill your system due to slightly higher noise.Quote from: smoothVTer on July 09, 2017, 06:18:21 pmThe MSP-FET seems available at theTI estore.

author: bson
author_rank: Unknown
timestamp: July 11, 2017, 08:56:28 am
content: The MSP-FET can either provide power or work with a self-powered board. Since I don't see the point of having the MSP-FET powering a board, ever, (all my boards are self-powered) I cut the supply lead on the adapter I use with Tag-Connect TC2030 cables. (Legged or non-legged, depending on board.) CCS can configure the MST-FET any which way it wants - the board will be self powered no matter what, and there is never an issue of multiple supplies wrestling.

author: smoothVTer
author_rank: Regular Contributor
timestamp: July 19, 2017, 03:22:11 am
content: Thanks for all the input everyone. I think its settled here that using the ez-FET circuitry as a programmer for external, disparate voltage msp430's isn't guaranteed to work, so to avoid it is good practice.Today got my hands on an MSP-FET, plugged it in, started CCS and programming/debug worked right out of the box. Excellent, they came back in limited stock.

author: alm
author_rank: Super Contributor
timestamp: July 19, 2017, 03:28:05 am
content: Thanks for the update! Good to know.