Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
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.