CYW20719 HCI recovery mode exit

[jakub]

Hello,

I would like to get startup traces from my application. My current setup is such that PUART is used in connection to other other MCU so I am routing the traces to HCI UART. The obvious problem is that when I program the device I cannot have the HCI port opened therefore I will miss on the startup traces. If I leave the port opened and I reset the device via button it enters recovery mode as the CTS pin is asserted. I have found in this thread https://community.infineon.com/t5/Bluetooth-SDK/CYW20719-HCI-UART-Raw-Mode/td-p/149812 that if I input "n" "w" or "r" into the terminal, it will exit recovery mode and start the application. However this is where the behavior becomes very confusing.

Here's what I do exactly and what output I am getting:

- I close all open HCI UART ports.

- I program the device. (programming complete the device is running)

- I open the HCI UART (eclipse terminal or hterm) and restart the device with a button - it enters recovery mode as CTS is asserted.

- I input "n" "w" or "r" (only one of them) into the terminal. Behavior here is unpredictable.

The application starts running every time ( no matter which letter I send) - that I have verified because phone can connect to the app and I can get traces. However the startup traces are more or less random. Sometimes they appear sometimes not. I have tried almost every combination of reprogramming the device, using different letters, reopening the HCI UART port, resetting the device but I cannot seem to produce a predictable outcome (sometimes the traces are there sometimes not).

Moreover I only get part of the startup traces. My program looks like this:

APPLICATION_START()
{
wiced_transport_init( &transport_cfg );
/* Select Debug UART setting to see debug traces on the appropriate port */
wiced_set_debug_uart(WICED_ROUTE_DEBUG_TO_HCI_UART);

WICED_BT_TRACE("**** App Start **** \n\r");

/* Initialize Stack and Register Management Callback */
if(WICED_BT_SUCCESS != wiced_bt_stack_init(bt_management_callback ,
&wiced_bt_cfg_settings, wiced_bt_cfg_buf_pools))
{
WICED_BT_TRACE("Bluetooth stack initialization failed!\r\n");
}
}

wiced_result_t bt_management_callback( wiced_bt_management_evt_t event,
wiced_bt_management_evt_data_t *p_event_data)
{

WICED_BT_TRACE("BT CB event: %d\r\n ", event);

switch (event)
{

...

I would expect that the very first trace I would receive is 

"**** App Start ****"

However these are the first messages I receive:

BT CB event: 21
BT CB event: 0

...

I have tried to look into here 

https://www.infineon.com/dgdl/Infineon-AIROC_HCI_UART_Control_Protocol_ModusToolbox.pdf-Software-v01...

for some leads on how to exit the recovery mode with the HCI commands but I found no mention of the "n" "r" or "w" commands (0x6E 0x72 0x77) and I did not figure out if there is another way.

So to recap my main questions:

1) How to exit the recovery mode with the HCI commands and HCI UART still connected so I can get the startup traces?

2) Why it is not showing the startup traces, but only the bluetooth stack traces (which are supposed to run on startup)?

I would also appreciate any other suggestions on how to deal with this.

Thanks,

Jakub.

[DheerajPK_41 · Accepted solution]

Hi,

There is a clear mention about autobaud mode/recovery mode in the document which you have attached. 

"The autobaud mode will attempt to detect the UART baud rate by checking the RX line for the bit pattern of an
HCI_RESET command. When detected, the HCI_RESET response is given at the same baud rate. In this mode,
most HCI commands will have no response. The HCI_DOWNLOAD_MINIDRIVER command, described in point 4
in HCI commands and events during a RAM download, will also have no response when the device is in
autobaud mode"

Also, recovery mode is used for primarily recovery of the device when the device goes to a bad state and program new clean firmware. This is a mandatory procedure on every new program download of the chip. At this mode, any unwanted/erroneous input to the Controller may put the controller into a bad state or put the controller back into the active application section, if it exists. 

One workaround in your case that may work is to use RTOS delay in the APPLICATION_START(). So that the BTSpy (HCI Transport) may get the initial traces starting from the APPLICATION_START().

As you said, If CTS is asserted and if you do a reset it will go into recovery mode. So reset button cannot be used to start the application to get the initial traces in the BTSpy (HCI Transport).

Having said that, I will check whether any standard method exists there to get traces from the beginning. I have seen different chips behaves differently, may be due to the difference in transport handling in the lower stack.

Thanks,

-Dheeraj.P.K