RTOS/CC2564: Enabling the BSC_FEATURE_A3DP_SOURCE feature in the A3DPDemo_Src sample take 3.3 seconds

Can, you please provide more details:
Host MCU, MCU clock speed.. How did you estimate/profile the function execution time? And since, it is a RTOS were there any task context switches etc??

Thanks

HI, yes here are the specs of our system.

- We are communicating with the TI over UART (flow control) 115200 baud.

- From an STM32F411 ARM running at 96 MHz.

- No RTOS and no context switches

- We are using the STM systick to determine the time it take for the BSC_FEATURE_A3DP_SOURCE to be enabled. Each systick is 1 millisec and we are counting roughly 3300 millisec.

Hi, that makes sense.
I just tried increasing the buadrate to 921600 and 230400 (double of 115200) but both resulted in a stack init failed after executing:
Result = BSC_Initialize(HCI_DriverInformation, 0);

Result = -4

Am not able to use even a slower baudrate like 9600 which also results in a stack init failed. Do I need to request the that the CC2564 be configured to a different baudrate first (using 115200 as default).

In the sample code we were suing A3DPDemo_Src 115200 was the vendor default baudrate.

Ah, I might need to call HCI_VS_InitializeBeforeHCIOpen to reconfigure the driver baudrate I'm guessing...

How did you change the UART/HCI baud rate? Since, you are using STM32 SDK, you can simply change the 'VENDOR_BAUD_RATE' in HALCFg.h

/* Define the baud rate that will be used for communication with the */
/* Bluetooth chip. The value of this rate will be configured in the */
/* Bluetooth transport. */
#define VENDOR_BAUD_RATE 921600L

Thanks

Hi Hari,

I tried changing the vendor_baud_rate to 921600L but this did not resolve the issue (still failed to open stack)

Also updated the ST UART baudrate to 921600.

i'm a bit confused though, if the baudrate of the TI CC2564 is by default 115200 (which seems to be the case) then wouldn't we need to communicate with is using the same baudrate initially?

If we try to communicate with the TI using 921600 baud but it's configured for 115200 then we will get a communication failure.

Does the TI have auto baudrate detection?

Thank you.

Yes, the controller after reset comes up at 115200. The Host stack sends the VS command to the controller to update to the new baudrate. The controller replies and after that changes tit he new baudrate..

Can, you take FW logs? If so, you should see a HCI command received from the host to change baudrate..

As, i noted earlier, i tried the profiling at different baudrates on MSP432 and it was easy to change.. I have n't played with STM32 host.. Will, give it a try hopefully next week..

Thanks

Hi Hari,
I see. Can you provide me with a snippet of the code you are using the update the baudrate? If possible something that shows you setting the new faster baudrate (using the 115200 uart at first) and then you updating your mcu code to use that new baudrate on the uart...
Thank you

Hi

On MSP432, this is all we do to change the baudrate. Change it, rebuild and run -

HAL.h
/* The following constant specifies the maximum HCI UART baud rate */
/* currently supported by this platform. */
// hnagalla - for tests
// #define HAL_HCI_UART_MAX_BAUD_RATE 2000000
#define HAL_HCI_UART_MAX_BAUD_RATE 115200

And on STM32, i think this is all you need to change -
'VENDOR_BAUD_RATE' in HALCFg.h
/* Define the baud rate that will be used for communication with the */
/* Bluetooth chip. The value of this rate will be configured in the */
/* Bluetooth transport. */
#define VENDOR_BAUD_RATE 921600L

Hi Hari,
Ok so in order to change the baudrate of the TI to 921600 we first need to communicate with it over 115200 uart buadrate.. correct?
I'm more confused about this aspect. The ST will first be using 115200 uart to tell the TI to use 921600 uart. Then after the TI cofirms it will change to the new uart the ST then needs to update it's own uart to 921600... is this correct?

I think I may have resolved the issue.

We edited the HCITR_COMReconfigure function and forgot to add code to change the baudrate ....

Either way, your advice has helped us a lot. I'll post the results after further testing.

Hi Hari,
It looks like fixing the HCITR_COMReconfigure was a necessary update on our part, however, it still did not resolve the issue.
It looks like the code starts to fail at the DownloadPatch function in BTPSVEND.c.  

Looking at the comments in the provided CC256XB.h file there is a mention of changing the baudrate as part of the patch. Worried that the patch is resetting the baudrate back to the default 115200.
Probably not happening but trying to figure out anything at this point.