2 of 2 people found this helpful
Instead of modifying the platform file, try commenting out the following lines in <WICED SDK>/libraries/bluetooth/mfg_test/internal/firmware/bt_firmware.c
if ( bt_host_update_baudrate( BAUDRATE_3MPBS ) == WICED_BT_SUCCESS )
fast_download = WICED_TRUE;
Can you clarify what you mean by impact to bt_mfg_test and production code, is this specific to the change you made to wiced_bt_uart_config?
With above modification bt_mfg_test seems to work without setting flow control in platform file. This greatly reduces my previous worries about the blind change in platform file. Thanks a lot.
It looks like that aky's fix is to slow down the bt firmware download speed only for bt_mfg_test. The fact that this makes "mbt reset COMx" work looks like the original problem for bt_mfg_test is simply "UART failed to run at 3Mbps w/o flow control".
The "impact" in original post is :
1. Production code was developed and tested mostly with stock wiced_bt_uart_config
2. bt_mfg_test is not working with stock setup, to make it work CTS & RTS are set for wiced_bt_uart_config.flow_control
3. Due to lack of knowledge for wiced_bt_uart_config, I wonder how this modification affects production code performance. One thing for sure is that string "wiced_bt_uart_config" does exist in binary : BTE.ThreadX.NetX_Duo.ARM_CM4.release.a, though we don't have any idea how it is functioning.
4. As an example of "impact", I found that the time needed from "wiced_bt_stack_init() is called" to "BTM_ENABLED_EVT" is slightly improved by 8 ms when wiced_bt_uart_config.flowcontrol is FLOW_CONTROL_CTS_RTS. I wonder if there are any other, especially negative, effects. I'm really curious to see both wiced_bt_uart_config.flow_control in all platforms, even for BCM94343Ws.