I think you are using wrong opcode.
The opcode for Enable_Device_Under_Test_Mode is 0x1803
So the command send should be [01 03 18 00] . Could you please test it with same?
1 of 1 people found this helpful
Could you please load the device with any of the application from WICED studio and then try sending HCI HCI_Enable_Device_Under_Test_Mode command
Also please make sure you are not putting the device into recovery mode.
Now you should be able to see the correct response.
Thanks & Regards,
Thank you Anjana for you continuing support. Appreciate it.
I loaded the headset app, and other apps, and this didn't work. There was no response to the reset command.
I often have to use the recovery mode in order to download code, but after that have not been using recovery mode apart from trying to get a reset response.
I then thought I would see why download from the Wiced studio worked, but reset from a terminal didn't. With a logic analyzer, I was able to see that Wiced studio tries to reset the device at 115200, but gets no response. It then resets the device twice at 3000000, both times receiving the proper reset response from the device.
After this, I went back to a serial terminal, changing the baud to 3000000 and was successfully able to get a reset response from the Headset app, but also a HCI_Enable_Device_Under_Test_Mode response:
The headset project must have discoverability and connectibility enabled as I was able to inquire for address and connect the Anritsu test box to the evaluation board. I believe this comes via the STANDALONE_HEADSET_APP flag in the make file, and when hci_control_management_callback receives a BTM_ENABLED_EVT event through this snip:
/* to work with stand alone */
wiced_bt_dev_set_discoverability(BTM_GENERAL_DISCOVERABLE, wiced_bt_cfg_settings.br_edr_scan_cfg.inquiry_scan_window, wiced_bt_cfg_settings.br_edr_scan_cfg.inquiry_scan_interval);
wiced_bt_dev_set_connectability(BTM_CONNECTABLE, wiced_bt_cfg_settings.br_edr_scan_cfg.page_scan_window, wiced_bt_cfg_settings.br_edr_scan_cfg.page_scan_interval);
/* maintain local application state */
app_state_cb.state = IDLE;
app_state_cb.audio_stream_state = APP_STREAM_STATE_STOPPED;
app_state_cb.call_state = HFP_STATE_IDLE;
app_state_cb.is_originator = WICED_TRUE;
When I start tests on the Anritsu box, and after sending the HCI_Enable_Device_Under_Test_Mode response, the Anritsu test box says that test mode has been refused and Wiced HCI gives this response via my serial terminal:
What does 19 18 00 02 00 01 00 mean? I can't find any reference to 0x18 in the Wiced HCI UART Control Protocol doc.
I think the problem may lie in the original response:
04 0e 04 01 03 18 0c
What does 0c mean?
Sorry, confusing BT HCI with Wiced HCI as there are two packet types in that serial debug snippet. The 19 18 00 02 00 01 00 is Wiced, the 04 0e 04 01 03 18 0c is BT. According to the Core_v5.0 BT spec:
04 - HCI Event Packet
0e - Command Complete
04 - number of parameters (i.e. Bytes) = 4
0c - Command disallowed
Why would test mode be disallowed? It didn't seem to be disallowed in your (Anjana) serial terminal log
I've tried using the Wiced HCI commands, but it seems as though the WICED HCI port is one directional:
Those 0x05 codes are for the NVRAM loads after I press reset on the Headset App
19 08 00 01 01 should be Set Visibility
19 01 00 should be reset
What mode is the UART port in, where it will receive and respond to BT HCI commands, send Wiced HCI packets, but not receive Wiced HCI packets?
With regards to the 19 18 00 02 00 01 00 message:
#define HCI_CONTROL_EVENT_CONNECTION_STATUS ( ( HCI_CONTROL_GROUP_DEVICE << 8 ) | 0x18 ) /* Connection Status */
Guess the PDF and *.h are not synchronized. I'm not sure what the payload is
1 of 1 people found this helpful
Okay, I finally got this working, with the Anritsu MT8852B putting the 20706 through its BR/EDR paces.
1. Reset Command:
01 03 0c 00
2. Scan Enable (for discoverability and connectibility):
01 1a 0c 01 03
3. Enable Device Under Test Mode Command:
01 03 18 00
4. Run test on Anritsu command after address of UUT has been returned from inquiry. Anritsu will send a Connection Request and the UUT host has a finite amount of time (timeout) to accept the request with:
5. Accept Connection Request Command:
01 09 04 07 9d 5d e1 91 00 00 01
The payload in that message includes the 6-byte BD_ADDR of the Anritsu box and a master/slave role flag
The link layer manager in the Anritsu box can now force the 20706 controller to transmit, frequency hop, etc.