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.

CC31XXEMUBOOST: RadiotoolCLI port allocation

Part Number: CC31XXEMUBOOST
Other Parts Discussed in Thread: CC3130

We want to use the RadioToolGui for different test purposes, but do not want to use the CC31xxMUBOOST interface. From the documentation it seems that only 2 of the 4 VCP of the FT4232 are used, the 2 "middle" ports. So i think i could two com ports adjacent to each other selecting the higher number port as control and the port below would then generate the nHIB signal, this is not working. Is there any way to use the RadiotoolguiCLI without using the BOOST PCB?

B.R. Flemming

  • Hi,

    What is your purpose of usage Radio Tools CLI? For production purpose is much better to integrate RF testing sl_ API calls into your main MCU firmware.

    Jan

  • For approval purposes we want to run the CC3130 as a stand alone, for this we plan to have a simple PC app basically a few bat files using the CLI version. For approval reason we do not want to have BOOST boards with load of pins when running the EMC test, but only a minimum system.

    For production we have embedded sl_API calls in the Main MCU.

    //Flemming

  • Hi Flemming,

    I understand your requirements. Unfortunately haven't tested such use case. Interaction between radiotools application and CC31xx devices via CC31xxMUBOOST is not well documented (missing source codes for radiotools application).

    Without source code of radiotools application is am not able help you. Please wait for answer from TI, but at this case I am slightly sceptical.

    Jan

  • Hello Flemming,

    In order to use RadioTool CLI, you simply need a UART to COM Port adapter/debugger while ensuring nHIB is high. 

    Then you'd use the following commands to establish a UART connection.

    BR,

    Seong

  • Hello Seong

    Tried it out, works fine through the BOOST card. From my trials I see that nHIB must be active, disconnect port and setting nHIB constant high results is "cannot connect..... check ports". Looking at the interface waveforms it seems all commands starts with nHIB asserting a low pulse causing the CC3130 to restart.

    Tried with two serial ports with adjacent port no (29, 30) selecting the uppermost (30) as communication port expecting port #29 to asserting a low pulse, no activity, it seems that the logical port number is accepted (no unhandled exceptions), but no activity, after timing out error message "cannot con.....pls check port no...."

    Putting an invalid port number return a number of unhandled exceptions, as it should do. It seems that there must be a serial interface FT4232 with a TI configuration EEprom content.

    CLI used : CC3xxx_RadioTool_1.0.3.18

    BR

    Flemming

  • Hi Flemming,

    Yes, FT2232D at CC31XXMUBOOST is pre-configured. You can check configuration by FT_Prog tool. For example my CC31XXMUBOOST have this configuration:

    CC31XXEMUBOOST.xml
    <?xml version="1.0" encoding="utf-16"?>
    <FT_EEPROM>
      <Chip_Details>
        <Type>FT2232D</Type>
      </Chip_Details>
      <USB_Device_Descriptor>
        <VID_PID>2</VID_PID>
        <idVendor>0451</idVendor>
        <idProduct>C31B</idProduct>
        <bcdUSB>USB 2.0</bcdUSB>
      </USB_Device_Descriptor>
      <USB_Config_Descriptor>
        <bmAttributes>
          <RemoteWakeupEnabled>false</RemoteWakeupEnabled>
          <SelfPowered>false</SelfPowered>
          <BusPowered>true</BusPowered>
        </bmAttributes>
        <IOpullDown>false</IOpullDown>
        <MaxPower>500</MaxPower>
      </USB_Config_Descriptor>
      <USB_String_Descriptors>
        <Manufacturer>TI</Manufacturer>
        <Product_Description>CC3100-BOOST</Product_Description>
        <SerialNumber_Enabled>true</SerialNumber_Enabled>
        <SerialNumber>TICC3100BP02</SerialNumber>
        <SerialNumberPrefix>TI</SerialNumberPrefix>
        <SerialNumber_AutoGenerate>false</SerialNumber_AutoGenerate>
      </USB_String_Descriptors>
      <Hardware_Specific>
        <Port_A>
          <Hardware>
            <UART>true</UART>
            <_245FIFO>false</_245FIFO>
            <CPUFIFO>false</CPUFIFO>
            <OPTO>false</OPTO>
            <HighIO>false</HighIO>
          </Hardware>
          <Driver>
            <VCP>true</VCP>
            <D2XX>false</D2XX>
          </Driver>
        </Port_A>
        <Port_B>
          <Hardware>
            <UART>true</UART>
            <_245FIFO>false</_245FIFO>
            <CPUFIFO>false</CPUFIFO>
            <OPTO>false</OPTO>
            <HighIO>false</HighIO>
          </Hardware>
          <Driver>
            <VCP>true</VCP>
            <D2XX>false</D2XX>
          </Driver>
        </Port_B>
      </Hardware_Specific>
    </FT_EEPROM>

    Jan

  • Hi Jan

    Thanks it just verified my next move, i played with the Eprom content and got same results as when using 3rd party VCP. Problem is not resolved, but root coarse is now known. I will find a way - thanks