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/MSP430G2201: MSP430G2201

Part Number: MSP430G2201
Other Parts Discussed in Thread: TIDA-00386, , MSP-FET, MSP430G2202, MSP430G2303, USB2ANY, MSP430G2553

Tool/software: Code Composer Studio

Dear Sirs /Madams,

I am using Launch pad to program MSP 430G2201 using TIDA-00386 remote code.

Upon Build when I click on Debug message as below appears. 

Error connecting to the target:

Could not find device (or device not supported)

I have connected Vcc, Gnd, RST and TEST pins of 2201 to the Launch Pad J3. I checked and confirmed correct connections offor Vcc and Gnd  on Pin # 14 and 1 of 2201 and so also the RST and TEST are connected correctly..


I have tried the above with CCS version 7 and earlier with version 6.2.

Target device is correctly configured as MSP430G2201 in CCS, USB port is also configured.

I have attached herewith two snap shots of wave forms of RST (Purple trace, channel 6 ) and TEST ( Grey trace channel 7). Both signals swing between 3.6 V and ground.

I seek you help so as to know where I may be going wrong.

Thanking you in anticipation.

J. A.

 

  • The voltage should be between 3.3 V and GND, make sure that there is no external power supply provided when the MSP-EXP430G2's eZ430 is connected. All of J3's jumpers should be completely unpopulated and jumper wires should be coming from the emulation side of the MSP-EXP430G2. If you look at Figure 1-12 Case 1a of SLAU320 then you notice that the RST line should only go low after two pulses on the TEST line and this is not seen in your screenshots.

    Regards,
    Ryan
  • Thank you Ryan.

    Yes, voltage is 3.3 between pin 1 and 14 of MSP

    There is no external power source. 3.3 V is from the J3 right hand pin in upper row, that is, Emulation side.

    None of the headers of J3 are populated with jumpers, the Emulation side header pins are used to connect Vcc, RST and Test pin of the MSP and gnd is connected to the Jumper J6.

    Well, the problem is that RST line does not go low only after two pulses of Test line, as in the snap shots sent by me.

    It is for this sake I posted my query seeking remedy or clue to mistake I may be making.

    I await your further guidance as to what else should I check for.

    Cheers,

    JA
  • Why doesn't the RST line appear to be pulled up to VCC? Can you provide an image of your board and setup?

    Regards,
    Ryan
  • Ryan,

    There seems something has gone wrong somewhere.  Soon  upon reading your query above I posted my reply with picture of the Launch pad connected to our trial PCBA.  That I did not get any response from you, I looked up this page on the Forum and did not find my reply. I am puzzled.

    Anyway here is my response to your doubt.

    Please note the RST line is pulled up and voltage on that is 3.3 V. Even in the snap shots of the logic analyser you can see the RST line is normally high.

    I will upload picture of the two boards connected together.

    Cheers,

    JA

  • JA,

    Your jumper wire appears pretty long and this sometimes interferes with SBW communication. Are you also confident that the MCU has been populated in the correct orientation and that there or no shorts present after soldering?

    Regards,
    Ryan
  • Ryan,

    I appreciate your prompt response.

    Had my earlier reply not vanished in cyber space, I would be, hopefully, successful in my trial.

    Well, your suggestion taken well. I will make the wires as short as possible.

    The MCU is soldered in correct orientation and also there are no shorts between the leads.

    Let me conduct next trial and will get back to you with my finding.

    Cheers,

    J A
  •  Ryan,

    Thank you for your suggestion.

    I shortened the jumper wires as short I could make them. There is no change. The target 2201 is yet not found. I have attached a picture of two boards connected together. In it the UART jumpers are in place. I tried debug after removing them as well. I changed the board on which 2201 is soldered. Before doing this change it was checked for soldering short, orientation of the chip, connection from RST and Test to Launch pad being correct, Vcc being 3.3 V. The components connected to 2201 are as in the schematic attached in file MSP Schematic.pdf .

    That  2201 is having only five components connected to it and also connection between Launch pad and our trial board being just four wires I feel fault is elsewhere. Moreover having checked the set up for mistakes multiple times I feel fault is not in hardware. Something which I do not understand about the CCS may the reason behind this malfunction.

    Please let me know where else can I look for a possible fault / glitch.

    Thanking you,

    JA

    MSP schematic.pdf

  • Your image makes it appear as though VCC is shorted to GND but I'll take your word that this is not the case, just the picture angle. I see that the decoupling capacitor is also connected, which is good. If you are unsure about CCS then you can attempt using IAR or FET-Pro430, but I doubt that the IDE is the issue. Have you tried using a different MSP430G2201 or MSP-EXP430G2 eZ-430? Do you have a MSP-FET tool available?

    Regards,
    Ryan
  • Ryan,

    Could not get back to you earlier as E2E site was down for maintenance.

    Well, please rest assured the Vcc and ground are not shorted. The Vcc is is connected through a red wire, which is in the socket plugged on to the header J3, left most pin in upper row. The GND is a white wire in the socket plugged on to the header J6 and is connected to upper of the two GND pins. Having said that and having further tried all that I could with my limited knowledge of MCUs and CCS, I feel that there is something wrong  I am may be doing in use of CCS.

    1. I used another board with 2201

    2. I used different Launchpad

    3. Each change also followed with checking out connections of Vcc, GND, Test and RST between the respective pins of 2201 and the Launchpad headers before next attempt to make Launchpad detect 2201.

    4. I must also supplement information on my successful use of the Launchpad to program a DRV 10983 with parameters which were obtained from EVM.

    5. Having failed in getting 2201 up, I once again programmed more DRVs successfully. Needless to say this clears LaunchPad, USB ports of laptop, USB cable, FET of Launchpad, drivers on laptop etc. of any malfunction.

    Back to your mail, please advise me about the MSP - FET tool you mentioned in your post.

    Thanking you,


    JA

  • Once again, the MSP430G2202 is supported by the MSP-EXP430G2 eZ430 so I am just as perplexed by the issue. At this point I can only recommend sky-wiring the FET to a G2201 device (with RST & VCC components) to see if there is an issue with the board. The design files (and this TI Design itself) were created by the Motor Drive team.

    Regards,
    Ryan
  • Jayant,

    In the latest image, I see Vcc coming from Emulation side of MSP430 Launchpad along with TEST and RST connections. and the GND would come from J6. In the image I see GND connection (Yellow wire) is hanging and white wire (Vcc) is connected to the board. Can you please confirm that 3.3V is applied at the device on your board ?

    Second, What is the Reset Capacitor value mounted on your board ? It cannot exceed 2.2nF. You can remove the cap from your board for time being and check.

    Jasraj

  • Ryan ,

    Thank you for your suggestion. I will take this forward and get back to you with results of my trial.

    Cheers,

    JA
  • Hi Jasraj,

    Yes, I have rechecked that 2201 is powered on with 3.3 V from Launchpad. I also tried not using 3.3 V from Launchpad and connected it from trial board where 2201 is soldered and for this I had removed the jumper of Vcc on J3.

    The decoupling capacitor on RST, originally 2.2nF was changed to 1.1 and finally removed. As such the suggestions made in your mail were tried out.

    In all I have tried three trial boards with various changes as mentioned above.

    The traces of RST and TEST signals as captured from logic analyser were attached to the first post in this string. What I am not able to comprehend is the RST signal going down before the pulse on TEST line goes down . Is it not what is causing this problem?

    Jasraj, I had tried, as mentioned in one of the earlier posts to Ryan, two different Launch pads, actually three as first one burnt out as 3.3 V from the trial board was also on when it was connected to Launch pad. Anyway on to the matter, I am not sure if there is something going wrong with my use of CCS as four connections to 2201 from Launchpad, repeatedly checked and confirmed to be alright do not seem to be the cause of malfunction seen.

    Please advise as to what else I need to look out for as probable cause.

    Cheers,

    JA
  • Jasraj,

    May I have your response to the above?

    As I waited to hear from you I did another trial.

    I used MSP430G2303, used firmware TIDA_ 00656. I get stuck similarly as in case of 2201.

    "MSP430: Error connecting to the target: Could not find device (or device not supported)"

    With this trial the probable cause like PCB layout or bad MCU or some other unseen error are not suspect.

    That I have used LaunchPad successfully earlier and have tried three different LPs, likely problem with LP is ruled out.

    Being new to CCS, as such not being confident of that I was not erring somewhere I tried CCS 6.2 and 7.

    While using TIDA_00656 and having set device as 2303 I noticed the last line, though greyed out, has link to 2553; please see attachment 2303.

    Similarly while using TIDA_00386 and having set the device as 2201 the last lines, greyed out , have links to 2252 and 2553.

    Are these of any consequence and probable cause of the no detection of the target device.

    Jasraj, I have done many trials and am at loss as to how to proceed further. May I request you to help me overcome the problem I face?

    Cheers,

    JA
  • Jayant,

    When you select a particular device while creating the project, appropriate command (.cmd) file is getting added to the project and you see previous command files being disabled.

    On your issue,  I cannot think of any possible problem that is not discussed on this thread. CCS 7 is something which I have never used and can't comment.

    How many boards are not getting programmed ?

    Jasraj

  • Hey Jasraj,

    Thank you for your prompt response.

    Yes, that is what I assumed since those other than active debug are greyed out.

    Ok. so I will try further with CCS 6.2 and let us see how does it go.

    I have tried three boards with 2201 and one with 2303, all of them are not getting programmed.

    I will be on the job and keep you updated on the progress.

    Cheers,

    JA
  • Jasraj,

    This is further to my earlier post.

    I uninstalled CCS6.2 and CCS 7. Re-installed CCS 6.2 and voila ..... I could debug program TIDA_00656. The same thing using TIDA_00386 does not yet find the target 2201.

    Now I feel there is something wrong in my usage of CCS. Being 6.2, may I seek your guidance?

    Cheers,
    JA
  • Jayant,

    It is good that you are gaining familiarity with the CCS resources, however this will not resolve your device connection issue between the LaunchPad eZ430 and target. This still has to do with the PCB hardware as you've been able to successfully communicate with a LaunchPad target using the installed CCS version.

    Regards,
    Ryan
  • Ryan,

    Thank you for quick response and for the nice words.

    Well, what you said about PCB hardware makes me think and I will relook at the layout around 2201, components soldered.

    I will be back with you with outcome of my next trial.

    Thank you for your support !

    Cheers,

    JA
  • Ryan,


    Before i report the outcome of my next trial I reviewed the work of yesterday.

    That I succeed with using CCS 6.2 with Debug using TIDA_00656,  I was comparing CCS configurations in case of 00656  and TIDA_00386.

    Please see the attached snapshot of the  CCS screen.

    5th and 6th lines underneath TIDA_00656 have I2.C and I2C.h whereas these are missing in case of TIDA_00386. I understand the I2C communication is not being used in this case as we have not used USB2ANy and are using LaunchPad with JTAG communication. As such presence or absence of I2.c and I2C.h ought not matter. Or being a beginner in usage of CCS I should rather seek opinion of Gurus like yourself or Jasraj.

    Second observation being target being MSP430G2553 whereas the TIDA_ 00656 is for 2303 and so also the MCU used by me was also the same. Question now is how did Debug go through successfully?

    I would be obliged by your throwing light on the above aspects and also if these things anything to do CCS not able to find target device when Debug command is given.


    Lastly the presence of nec_remote.c and nec_remote.h in case of 00656 and absence in case of 00386 also baffles me as TIDA_00386 is for remote programming. Please enlighten me on this as well.

    Cheers,

    JA

  • So you were able to program a MSP430G2303 device using a project set up for a MSP430G2553? At this point I'd recommend you use a MSP-FET so that we can know if similar behavior is observed without the eZ430. I cannot provide comments for the file structure of projects I have not worked with.

    Regards,
    Ryan
  • Ryan,

    Looks like there is some misunderstanding. I used Launchpad and a trial board with 2303 soldered on it. I have not used eZ430.

    Cheers,

    JA
  • Jayant,

    The eZ430 is the FET on-board the LaunchPad which you are using to program the MSP430G2303, using firmware initialized for a MSP430G2553.

    Regards,
    Ryan
  • Ryan,

    I do not have MSP-FET. Can LaunchPad be not used instead of MSP-FET?

    Cheers,

    JA
  • It should but results so far have shown that communication between the FET and target device are faulty, a different tool would be useful for debugging communication between the two.

    Regards,
    Ryan
  • Jayant, Great to here it.

    • If memory map of communication code and target write locations are same, usually debug will go through (here both the devices are from same family and same memory maps)
    • The i2c.c/.h and nec_remote.c/.h is purely software re-architecture of code. E.g. the I2C and NEC protocol was handled in main.c itself in 386 code and moved to separate files in 656 case (656 code is written after 2 years that of 386 and code architecture and software has evolved over time). There should not be a functional problems associated with two architectures.

    Jasraj 

  • Jasraj,

    Thank you for your prompt response and support so far.

    I am on to my forward journey and have debugged. On to the programming of the remote control I need further help.

    Upon following the Steps to change remote codes the message in the console is as follows instead of that shown in the screen # 4 

    MSP430: There were 1066 (code) and 14 (data) bytes written to FLASH/FRAM. The expected RAM usage is 101 (uninitialized data + stack) bytes.

    Is the code size 1066 instead of being 900 as suggested indicates need for erasing flash before trying to change codes to match those of the remote? Ignoring the difference in number of bytes I resumed the program by clicking on Run

    Next upon inserting break at kine 112 and then pressed a key on remote, moved the cursor to line 110 but did not see the pop up window with Hex code. as depicted in screen 6.

    May I once again seek your help in this matter?


    Thanking you in anticipation.


    Cheers,

    JA

  • Jasraj,

    Please ignore my previous post. I got the programming of the remote code under control. Now that I am able to progress further, I would like to express my gratitude to all the members of your team.

    Support was good and timely and I appreciate candid opinions / views of some.

    Cheers,

    Jayant Arora

**Attention** This is a public forum