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.

HCI testing commands: "LE_Test_End" not working properly?

Other Parts Discussed in Thread: CC2541

Hi,


I'm about to prepare an application based on the CC2541 for Bluetooth certification. I now ran into problems with the HCI command "LE_Test_End" after "LE_Receiver_Test" and "LE_Transmitter_Test" in Direct Test Mode:

I'm using the Host Test Release "CC2541_SmartRF_HostTestRelease_All.hex" from the latest BLE software stack V1.4.0. Communication with the test system is established via the UART interface of the CC2541.


In the TI Wiki "http://processors.wiki.ti.com/index.php/PTM" (Navigation trail: Category:BluetoothLE » How to Certify your Bluetooth product » PTM) I found the test command specification for "LE_Test_End" as follows:

Command to end either the Tx or Rx test: HCI_LE_Test_End
Send this hex command to end Rx or Tx test: 01 1f 20 00
After sending the HCI_LE_Test_End command to the device, the following response will be returned, indicating that the command was received and the test has ended: 04 0e 06 01 1f 20 00 xx xx
xx xx = 00 00 if Tx test was performed
xx xx = Total number of received packets if Rx test was performed.

The highlighted bytes are exactly the response the test system expects when a "LE_Transmitter_Test" or "LE_Receiver_Test" is terminated.

However, with the above mentioned Host Test Release firmware the response always looks like this:
04 0e 06 00 1f 20 00 xx xx


I.e. there is a difference in the 4th byte (00 instead of 01) which leads to a failed test in connection with the test system.

Is this a bug in the Host Test Release firmware or does this byte 00 have a useful meaning?

However, the Transmitter Test and the Receiver Test are carried out on the CC2541. After termination of a Receiver Test the number of packets (xx xx) is displayed correctly.

Best regards, Matthias

  • Hi,

    This is a bug. The byte carries no 'real' significance in this case, but is used as a flow control token. It will probably be hard-coded to 1 or something else in the next release, but if you can get your test system to ignore it, that's safe.

    BR,
    Aslak

  • Hi Aslak,

    Thank you for the quick response.


    Unfortunately, the test system is a third party automated test system where I don't have the possibility to change the code. Therefore, I'm highly interested in a bug fix/next release. Do you know if there is something planned in the near future?

    Is there maybe an older version of the Host Test Release firmware which does not have this problem? I just need the Direct Test Mode and its LE test commands for the Bluetooth certification.


    Thanks, Matthias

  • hi,Joerg

    from your statement,

    it seems that you have worked well with the PTM.

    but it has no respond to my board, my code is like this:

    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.
    HalLedSet( HAL_LED_2, HAL_LED_MODE_FLASH );
    HalUARTWrite(0,"version:1.2" ,11);
    // osal_pwrmgr_device( PWRMGR_ALWAYS_ON );

    HCI_EXT_EnablePTMCmd();
    }

    is there any problem?

    thx.