Yes, CY_APP_PATCH_LIBS += wiced_uart_raw_mode_lib.a patches the Firmware.
wiced_transport_init() Initializes and configures the transport. The registred wiced_tranport_data_handler_t callback function handles the received data by detecting them.
"seems to Block until there is some input received on the UART, ... this is not ideal." ->
It is expected. The callback function will get called when there is a message.
May I know what is your requirement? What functionality you are expecting otherwise?
Thanks for the response. We have found that once "CY_APP_PATCH_LIBS += wiced_uart_raw_mode_lib.a" was added to the make file AND a 'Clean' was performed then we were able to see raw-mode output on the HCI UART.
Regarding the Blocking behavior during the transport initialization:
Since our design is IO limited (we are using all available IO pins) we need to use the HCI UART as a general purpose UART for communication to another IC in our system. Since the CYW20179 is the 'Master' within our system, it is difficult to insure that the connected peripheral device can output a message on the UART interface in order to un-block the CYW20179 transport initialization.
Our expectation would be that in Raw Mode, the HCI UART should function like any other general-purpose UART. (For example, if we were able to use PUART, it would initialize fully without needing some input from an external device). So is there a way to make the transport initialization run to completion (i.e. non-blocking) strictly based on CYW20179 internals?
Hi, ... I'm wondering if there is any update or additional feedback on this issue?
HCI UART in Raw mode works as a general purpose UART. You can send/receive raw bytes through it.
The transport configuration is done in the application in wiced_transport_cfg_t. Kindly check.
It does not block any input data as you said. Are you observing any issue in the HCI Raw data transmission?
Could you please provide me some steps to reproduce the issues?