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.

"MSP430: Error connecting to the target: Unknown device" using brand new MSP-FET, 14 pin target board and active cable, and CCS 6.1

Other Parts Discussed in Thread: MSP-FET, MSP430L092

Title says it all really, I'm delving into MCU programming, and so acquired the tools necessary for the job. So far though, I'm stuck on an error that seems to keep cropping up for many on this forum, and it's most frustrating.

I have an L092 chip placed in my target board, which is in turn connected by the active cable to the MSP-FET, which is plugged into my PC. I know the chip and target board work (at least) since (as per the documentation), when the target board is powered the L092 loads the default blink program from the target board EEPROM, and blinks the onboard LEDs 3 times.

All I want to do is get started in programming it myself. I opened up CCS (6.1.0.00104), and created a new project targeting the L092 using the blink template. It builds fine, but when I try to upload (click debug) I get "MSP430: Error connecting to the target: Unknown device". I'm at a loss at what to try, since aside from solder the headers onto the target board, I haven't even done anything.

It may be worth mentioning that CCS told me that the MSP-FET needed a firmware update the first time I tried this. I let it run, and have had this problem since. I *believe* I have the newer MSP-FET as opposed to the old MSP-FET430UIF, but I wouldn't have thought that that would be a problem. This is all running under Windows 8.1. The MSP-FET shows up as two devices in device manager: MSP Application UART1 (COM3) and MSP Debug Interface (COM4).

Can someone tell me what is going wrong? If this is not going to work then I will be sending all of this straight back to TI for a refund.

The sample code is below, nothing special.

//******************************************************************************
//   MSP430L092 Demo - BlinkLED
//
//   Description: BlinkLED For L092 Target board using the Boost Converter LEDs
//
//*******************************************************************************
//
//                MSP430L092
//                -----------------
//            /|\|                 |
//             --|RST              |
//               |                 |
//   Boost    -->|P1.2             |
//               |                 |
//                -----------------
//
//   L. Westlund
//   Texas Instruments Inc.
//   May 2010
//   Built with Code Composer Studio Version: v5
//******************************************************************************
#include <msp430.h>

int main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT
  CCSCTL0 = CCSKEY;                         // open CCS
  CCSCTL4 = SELA__HFCLK+SELS__HFCLK;		
  CCSCTL5 = DIVA__4;						
  CCSCTL8 = 0;								
  do
  {
    SFRIFG1 = 0;
    CCSCTL7 = 0;
  }
  while( SFRIFG1 & OFIFG );

  P1DIR = 0x04;                             // P1.2 as output

  TA1CCR0 = 24000;
  TA1CCTL0 = CCIE;
  TA1CTL = TASSEL_1+ID_3+TACLR+MC_1;
  __bis_SR_register(GIE);                   
  while(1);

}

// Timer A1 interrupt service routine
#pragma vector=TIMER1_A0_VECTOR
__interrupt void Timer_A1 (void)
{
   P1SEL1 ^= 0x04;
   P1SEL0 ^= 0x04;                          // Toggle ACLK at P1.2
}

  • Hello Jashan,

    Do you have the correct jumpers in place on the active cable board? Please see table B-4. MSP-TS430L092 JP1 settings on page 48 of the HW User's Guide --> www.ti.com/lit/slau278

    Regards,
    JH
  • Hi Jace,

    My apologies, I did not say specifically: I am trying to program an MSP430L092 chip, and as a result purchased the MSP-TS430L092 Target Board, which does not have the jumpers to referred to (and I believe is specific to programming this chip?)

    I have it set exactly as is shown here

    The only difference is that I haven't soldered on the EEPROM headers yet. Jumpers are as pictured.

    Any ideas? Thanks!

  • Jashan,

    From the picture provided, none of the jumpers are closed on the active cable board. From the documentation I pointed to JP2 must be closed for RST line to function, and JP1 needs to be set according to your power setup. If you want the FET to power both the active cable board and the target board, both positions of JP1 must be closed.

    Regards,
    JH
  • Hi Jace,

    Sorry again! I did not notice that in the picture. In actual fact my jumpers are all set like you specified for the FET to power the active cable board and target board. Here's a picture of my boards.

    Anything else you could recommend? Thanks!

  • Jashan,

    I'm sure you are doing this when connecting to CCS, but I don't see the chip in the socket in the picture you posted.

    I would double check to make sure CCS is up to date and the FET as well. You can also try the Elprotronic Lite FET-Pro430 SW as an alternative means of downloading the code. Beyond that, I would double check your solder connections to ensure no accidental shorting.

    Regards,
    JH
  • Hi Jace,

    Yes, I most definitely am inserting the chip when attempting to program. As I mentioned before, the default program on the EEPROM does seem to get loaded by the inserted chip, and flashes the LEDs 3 times.

    I will try out the Elprotronic software and see if I get anyway, and report back.

    Thanks!
  • Hi Jace,

    Sorry it has taken a while to get back, but I've made some progress.
    I have tried using both CCS and Elprotronic to get some sort of response from the target board, both with no success. (The Elprotronic software does not even have the L092 as an option for connection.)

    I finally found the MSP430Flasher CLI tool (v1.3.4), and decided to try using that. Initially it gave the same result as all the other attempts ("ERROR: Unknown device"). However after looking at the tools documentation I found the "-o L" flag which is meant to set the software in "L092 mode". Running the flasher with this flag is successful, and I have since been able to write txt binaries from CCS to the chips EEPROM using the flasher tool.

    I would like to know why this problem exists? I can't understand why after setting up CCS to target the specific chip I am using it fails to recognise and program it. If there is a flag I am meant to set in the CCS compiler options somewhere, or some other way to do this then it is poorly documented. On the other hand if this is a bug I hope you can solve quickly. I feel this was far too much hassle to get the most basic of things going.
  • Jashan Bhoora said:
    I would like to know why this problem exists? I can't understand why after setting up CCS to target the specific chip I am using it fails to recognise and program it. If there is a flag I am meant to set in the CCS compiler options somewhere, or some other way to do this then it is poorly documented.

    I haven't got a L092 device to try it, but when a L092 project is created in CCS 6.1 under the Debug -> MSP430 Properties -> Download Options there is a check-box for "Copy application to external SPI program memory after program load":

    I think selecting "Copy application to external SPI program memory after program load" will cause CCS to use "L092" mode and program the external EEPROM.

    [The "Copy application to external SPI program memory after program load" option is grayed-out in the CCS GUI unless the project is for a L092 device]

  • Hi Chester,

    Thanks for the advice. As it happens I already knew about this setting, and had tried both options. To be sure I tried it again and got the same "Unknown device" response. My understanding is that since the L092 doesn't have non-volatile memory onboard (and so requires the external EEPROM on boot) an developer has the option to either write their program directly to the RAM of the L092, or to the EEPROM and let the L092 load it itself (is it would in a real scenerio).

    From what I can make of this, the problem I'm seeing seems to be happening before this even becomes relevant. The FET just doesn't seem to be configured correctly by the IDE for debugging the chip, which is what I cannot understand since I have already set the correct target.
  • Jashan Bhoora said:
    From what I can make of this, the problem I'm seeing seems to be happening before this even becomes relevant. The FET just doesn't seem to be configured correctly by the IDE for debugging the chip, which is what I cannot understand since I have already set the correct target.

    I agree that the problem occurs before CCS even tries to program memory - in that the error occurs on attempting to open the device.

    Given that MSPFlasher v1.3.4 can program the L092, but CCS 6.1 can't suggests there is a bug in how CCS 6.1 calls the MSP430.dll (interface to the FET) when a L092 is used.

    While I haven't got a L092 to fully investigate, as a quick test I used http://www.rohitab.com/apimonitor to monitor the calls CCS 6.1 and MSPFlasher v1.3.4 were making to MSP430.dll when attempt to access a L092.

    The 4th parameter in the MSP430_OpenDevice function is:

    \param DeviceCode: Activation code for devices. Example: L092 or C092

    MSPFlasher v1.3.4 is setting DeviceCode to 0xA55AA55A.

    Whereas CCS 6.1 is setting the DeviceCode to zero. This could be the cause of why CCS 6.1 fails to access the L092. Can someone from TI confirm if this is a bug?

  • Chester Gillon said:
    MSPFlasher v1.3.4 is setting DeviceCode to 0xA55AA55A.

    Whereas CCS 6.1 is setting the DeviceCode to zero.

    The ccsv6\ccs_base\common\targetdb\devices\MSP430L092.xml file in a CCS 6.1 installation has the following:

    <property Type="stringfield" Value="Normal mode = 0xA55AA55A;ROM mode = 0x5AA55AA5" id="EmulationMode"></property>
    <property Type="stringfield" Value="choicelist(emuType[Emulation mode], Normal{@linkerCmd=lnk_msp430l092.cmd @ccxml:MSP430.emuType=Normal}, ROM{@linkerCmd=lnk_msp430c092.cmd @ccxml:MSP430.emuType=ROM});" id="ProjectOptions"></property>

    And the ccsv6\ccs_base\common\targetdb\drivers\msp430_emu.xml file has the following:

                    <isa Type="MSP430L092" ProcID="0x6b800000">
                                    <driver file="../../DebugServer/drivers/msp430_emu.dvr">
                                                    <connectionType Type="MSP430"/>
                                                    <property Type="hiddenfield" Value="msp430.dll" id="dllName" />
                                                    <property Type="hiddenfield" Value="MSP430" id="interface" />
                                                    <property Name="Emulation Type" desc="Emulation Types" Type="choicelist" id="emuType" Value="0">
                                                                    <choice value="Normal"/>
                                                                    <choice value="ROM"/>
                                                    </property>
                                                    <property Type="hiddenfield" id="L092ActivationCode" Value="0xA55AA55A"></property>
                                                    <property Type="hiddenfield" id="C092ActivationCode" Value="0x5AA55AA5"></property>
                                                    <property Type="hiddenfield" id="supportExtMemDL" Value="true"></property>
                                                    <property Name="JTAG/SBW Speed" desc="JTAG/SBW Speed" Type="choicelist" id="interfaceSpeed" Value="0">
                                                      <choice Name="Slow" value="2"/>
                                                    </property>
                                    </driver>
                    </isa>

    i.e. CCS 6.1 device XML files contain the value required for the DeviceCode on a L092, and the EmulationMode selection appears under the CPU Properties in the Target Configuration file for a MSP430L092. The CCS 6.1 msp430_emu.dvr driver which calls the MSP430.dll is closed-source, so I can't tell why the msp430_emu.dvr driver doesn't pass the DeviceCode to the MSP430_OpenDevice function.

    However, the MSP430.dll is open source, so pending a fix to CCS 6.1 it may be possible to modify the MSP430.dll so that the MSP430_OpenDevice function assumes a suitable DeviceCode when the device type is a L092

  • This is an interesting breakdown of what is happening. Following what you found I tried to compile my own copy of MSP430.dll. I wanted to use it "as is" first to see if I got the same error, then hardcode MSP_OpenDevice and see if anything changed.

    Unfortunately, when I switched the CCS version with my version, CCS complained that it could not find the library (in the same path). I looked at the export directories of both DLLs to compare, and I found the my version does not expose 18 functions that the CCS one does(its the same with the MSPFlasher DLL). All of them are version 3.5.0.1, and I'm sure I have included all the necessary dependencies too. (I got no errors or warnings on final compilation either). I can only assume that CCS doesn't see my DLL because of the missing functions, but I'm unsure why they are not there. It seems to have something to do with HIDAPI (one of the 3rd party dependencies), since it is the functions from that library that are missing, though it is definitely included linked in VS.

    If we can't get around this we will probably just have to hope and wait...
  • All,

    Thank you for this in-depth analysis and for bringing this to our attention. This has indeed been identified as an issue and is being scheduled to be addressed. In the mean time, the following should be a workaround to get you going.

    When adding RF430 support, the list box strings for the L092 have been changed
    from "L092"/"C092" to "Normal"/"ROM".

    CCS simply adds "ActivationCode" to the string above when checking
    for the device code. However, those fields are still named "L092ActivationCode"
    and "C092ActivationCode".

    A quick workaround is to fix
    ccsv6/ccs_base/common/targetdb/drivers/msp430_emu.xml, by replacing:

    L092ActivationCode with NormalActivationCode
    C092ActivationCode with ROMActivationCode

    or alternatively, change back the emulation type values (however, in that case
    it's important to only do this for the L092, not the RF430):

    Normal -> L092
    ROM -> C092


    Hope this helps!

    Regards,
    JH
  • Excellent! The fix has worked for me! Thank you both very much!

    Out of interest Jace, could you tell me why the MSP430.dll I compiled does not export the same set of functions as the one bundled with CCS and MSPFlasher? I linked all dependencies, but did I miss something else?
  • Jashan,

    Unfortunately, I do not have any insight as to why.

    Regards,
    JH
  • Jashan Bhoora said:
    I can only assume that CCS doesn't see my DLL because of the missing functions, but I'm unsure why they are not there. It seems to have something to do with HIDAPI (one of the 3rd party dependencies), since it is the functions from that library that are missing, though it is definitely included linked in VS.

    I built the MSP430.dll from SLAC460L (v3.5.0.001), and got the same problem when I copied the MSP430.dll built from source into the CCS ccsv6\ccs_base\DebugServer\drivers directory.

    The issue is that the hidapi-hidapi-0.8.0-rc1 Visual Studio project builds a Dynamic Library (.dll) configuration by default.

    Therefore, to allow the MSP430.dll to be used by CCS you have to copy the hidapi.dll built by hidapi-hidapi-0.8.0-rc1 into the CCS ccsv6\ccs_base\DebugServer\drivers directory.

    The MSP430.dll which is installed by CCS must have used a hidapi compiled as a Static Library, rather than Dynamic Library. I tried to change hidapi-hidapi-0.8.0-rc1 to compile as a Static Library, but got errors and didn't investigate.

**Attention** This is a public forum