• Not Answered

which pins should be used as UART in DTM?

details about BLE Stack 1.2 Released:

http://e2e.ti.com/support/low_power_rf/f/538/t/166931.aspx

The article referred:

- Support for "Production Test Mode" has been added, allowing a BLE application in a "single-chip" configuration to temporarily expose the HCI over the UART interface when triggered externally to do so (e.g. hold a GPIO pin low during power up). This allows the device to be connected to a Bluetooth tester in order to run direct test mode (DTM) commands on a production line using the final release firmware, while leaving the UART GPIO pins available for the application to use at all other times

1) Which pins(CC2541) shoulod be used as UART in DTM? Or which pins you will recommend to be used as UART in DTM?

2) "(e.g. hold a GPIO pin low during power up). " Which GPIO pin should be used?

Thanks.

25 Replies

  • Yes!  Same problem here!

    The README.txt of BLE Stack 1.2 mentions:

    - Support for "Production Test Mode" has been added, allowing a BLE application
      in a "single-chip" configuration to temporarily expose the HCI over the UART
      interface when triggered externally to do so (e.g. hold a GPIO pin low during
      power up). This allows the device to be connected to a Bluetooth tester in
      order to run direct test mode (DTM) commands on a production line using the
      final release firmware, while leaving the UART GPIO pins available for the
      application to use at all other times

    We are going to do the Qualification Test to our product at Bluetooth Qualification Test Facilities (BQTF).

    Does this new feature help?  How do we use it exactly?

    Best regards,

    Jeff

  • In reply to Peng Jeff:

    Hi,

    Assuming that you are familiar with our BLE stack, the SW needs modification at applications layer to support PTM testing even though PTM is built in for BLEv1.2. We don’t have PTM documented yet, but the code below can be used in (for example) simpleBLEPeripheral.c  to show of how the application checks whether an MT8852B tester is connected during startup. It works by checking whether GPIO P0.4 is held low, and if it is then the application will enable PTM. Anritsu has implemented software in the MT8852B that will hold that line low to signal to the CC2540 (Pin P0.4 is exposed on the DB-9 header connecting to the MT8852B). The other pins are the normal pins used for the HCI interface when using a network processor build.
    Essentially, all PTM does is allows you to expose the physical UART HCI interface in a single-chip build, only when triggered by some action during initialization. In the case of the sample code, the action is pin P0.4 being held down by the MT8852B. On the production line when the MT8852B is connected, the device will initialize into PTM. Under all other circumstances (such as when the end-user powers up the device as a final product), the GPIO will not be held low, so the device will initialize as normal. The HCI interface is not exposed to the physical UART interface, and those GPIO pins can be used by the application for anything. This allows one single software build to be used for both production testing as well as the final application.
    Add following to constant declaration
    //-----------------------------------------------------------
    // TI BLE CC254x Production Test Mode
    #define PTM                   4
    #define RDY                   5
    #define PDUP0                 5
    #define P0ICON                0
    #define TESTER_CONNECTED()    (P0_4==0)?TRUE:FALSE
    //-----------------------------------------------------------
    Define and use the following function to setup the interface;
    //-----------------------------------------------------------
    /*******************************************************************************
     * @fn          llSetupPTMTestPort
     * @brief       This routine is application sample code that shows how to setup
     *              two GPIOs used as the RS232 flow control pins for the Production
     *              Test Mode header interface. This interface assumes UART0, Alt 1.
     *              The RTS is mapped as a pulled-up input and is used to determine
     *              if a Tester connector is attached to the PTM header. If RTS is
     *              asserted (low), then the connector is attached and PTM can be
     *              enabled; otherwise the application can boot normally. 
     *
     *              Note: The DUT's RTS is de-asserted. If PTM is enabled, then when
     *                    this pin is configured as part of the UART flow control,
     *                    its value will be asserted, which indicates to the Tester
     *                    that the DUT is ready.
     */
    void llSetupPTMTestPort( void )
    {
      // ready UART0, Alternative 1 for the application to monitor
      P0SEL &= (~BV(PTM) & ~BV(RDY)); // GPIO
      P0DIR &= ~BV(PTM);              // input; this is Tester's RTS
      P0DIR |=  BV(RDY);              // output; this is Tester's CTS
      P0    |=  BV(RDY);              // de-assert Tester's CTS
      P0INP &= ~BV(PTM);              // pull-up/pull-down depending on P2INP
      P2INP &= ~BV(PDUP0);            // pull-up
      return;
    }  
    //-----------------------------------------------------------
    Add the following to the Init function (Ex. SimpleBLEPeripheral_Init) and put the previous content in the else case
    //-----------------------------------------------------------
      llSetupPTMTestPort();
      
      // check if Tester's RTS is asserted
      if ( TESTER_CONNECTED() )
      {
        // it is, so enable PTM
        // Note: It is assumed when the Tester is finished, the connector will be
        //       removed from the DUT's header, and the DUT will be reset/power cycled.
        
        osal_pwrmgr_device( PWRMGR_ALWAYS_ON );
        
        HCI_EXT_EnablePTMCmd();
      }
      else
      {
        //moved here due to PTM test
        osal_pwrmgr_device( PWRMGR_BATTERY ); 
        //Copy and Past the original init content here
      }
    I hope this helped you to understand PTM further.
    Br
  • In reply to Joakim Lindh:

    Hello Nick,

     

    Already tried incorporating the mentioned changes and did see the GPIO P0.4 is held low by MT8852B but still failed to perform test.

    Which EUT control shall be selected from the Anritsu tester application?  the baudrate to use?

     

    thank you

     

  • In reply to Joakim Lindh:

    Hello Nick,

    Thanks for the great detail!

    Our Bluetooth Qualification Test Facilities uses the BITE T1111 RF Test System.
    I need to confirm how the pins connect to RS232 when I use your PTM code.

    CC2540  <<<=======>>>  Tester

    UART0, Alt 1.                          RS232C
    ----------------------------------------
    P0.2:RX    <<<==========  TX
    P0.3:TX    ==========>>>  RX
    P0.4:CT    <<<==========  RTS
    P0.5:RT    ==========>>>  CTS
    ----------------------------------------

    Are these connections correct?  
    Do I have to connect all these four pins?
    Are there other pins I should connect to RS232?

    And, what baudrate should I use?

    Thanks for your help!

    Jeff

  • In reply to Peng Jeff:

    Hi Jeff,

    I have not run the BITE system myself but I do know some of our customers does so it should work fine!

    Connect all 4 pins as you have shown. The set-up opf the instrument should be:

    Baudrate -> 57600

    Databits -> 8

    Stop bits -> 1

    Parity -> None

    Protocol -> None

    Let me know if it works!

     

    -Per

  • In reply to Per H:

    Hi,

    I have updated some information regarding DTM/PTM on our wiki: 

    http://processors.wiki.ti.com/index.php/PTM

    Have a look there and see if you've missed anything.

    Br

    http://processors.wiki.ti.com/index.php/PTM

  • In reply to Joakim Lindh:

    Hello Nick,

    Still not able to make it work...
    From the wiki you mentioned that the DUT's RTS will be asserted, which indicates to the Tester that the DUT is ready.  But P05 remains high even after EnablePTM.
     
    I also tried using BTool to issue the HCIExt_EnablePTM to a cc2541 with CC2541_SmartRF_HostTestRelease_All.hex firmware.  
    I got an unknown hci command status.


    12] : <Tx> - 03:03:41.047
    -Type  : 0x01 (Command)
    -Opcode  : 0xFC0E (HCIExt_EnablePTM)
    -Data Length : 0x00 (0) byte(s)
    Dump(Tx):
    01 0E FC 00

    ------------------------------------------------------------------------------------------------------------------------
    [13] : <Rx> - 03:03:41.109
    -Type  : 0x04 (Event)
    -EventCode : 0x0E (HCI_CommandCompleteEvent)
    -Data Length : 0x04 (4) bytes(s)
     Packets  : 0x01 (1)
     Opcode  : 0xFC0E (HCIExt_EnablePTM)
     Status  : 0x01 (Unknown HCI Command)
    Dump(Rx):
    04 0E 04 01 0E FC 01

    any idea what i've done wrong?

    tnx, J

  • In reply to J Chan:

    Hi J,

    Did you follow the code examples in the "How to Use PTM from an Application Point of View" section? Have you connected the Anritsu correct?

    As for the HCIExt_EnablePTM it says in the TI BLE Vendor Specific HCI Guide: 

    This command is used to enable Production Test Mode (PTM). This mode is used by the customer during assembly of their product to allow limited access to the BLE Controller for testing and configuration. This command is only available when the BLE Controller is built without external access to the Controller (i.e. when no transport interface such as RS232 is permitted). This mode will remain enabled until the device is reset. Please see the related application note for additional details. Note: This command is only allowed as a direct function call, and is only intended to be used by an embedded application.
    So you cant use the HCIExt_EnablePTM command over a serial connection. You could use HCI_LE_Transmitter_Test instead, as described on the wiki.
    Br 
  • In reply to Joakim Lindh:

    hello nick,

    yes, did follow the sample code snippet. and did verifiy the function was called by setting a break point.

    i was able to run the anritsu tester with the cc2540 module running the CC2540_SmartRF_HostTestRelease_All.hex.  EUT control set to rs232 with 57600 baudrate.

    but for this PTM, regardless whether i set the EUT control to RS232 or bi-wire, it doesnt work.  how do i know whether cc2540 is really running in test mode?

     

    thanks

    regards, J

  • In reply to J Chan:

    J, 

    Make sure that you do have HCI_DISABLE_UART defined. To check if the HCI_EXT_EnablePTMCmd was successful, make sure that the return value is 0x00. 

    Br