Hello, I have a straight question.
Should HCI UART CTS be connected with an external pulldown resistor when HCI UART is unused or can it be left floating?
I'm asking this because I have a strange interaction with HCI and PUART in my application related to HCI UART CTS state: if HCI UART CTS is pulled high then PUART does not receive data or receives corrupted data, while if HCI UART CTS is low then everything works as expected.
PUART port is configured with
// Avoid conflict between PUART_RX and CLK_REQ bonding
#define cr_pad_fcn_ctl_adr4 0x003201b8
#define REG32(x) (*(volatile unsigned*)(x))
unsigned val = REG32(cr_pad_fcn_ctl_adr4) & ~(0x0000F000);
REG32(cr_pad_fcn_ctl_adr4) = val | (7 << 12);
wiced_hal_puart_select_uart_pads(WICED_P04, WICED_P31, 0, 0);
After reading some thread on PUART I also tried moving the following code from ISR to a periodic timer but with no effect.
cbuf_put((void *)p_priv->p_init->p_rx, byte); // This puts data in a local buffer read by application
Since it seems to depend on HCI then I also tried with both
to disable HCI but none of the seems to work and the behavior is the same.
I'm struggling with this strange problem and we have 1000 pcs in production that need to use the PUART port.
Please check whether you have followed the reference schematics for your custom board or not. https://www.cypress.com/documentation/development-kitsboards/cybt-343026-eval-ez-bt-module-arduino-e...
In your case you can set wiced_set_debug_uart(WICED_ROUTE_DEBUG_NONE) because you donw' want to use HCI UART and using PUART for other communication.
Generally you can leave it unconnected if you are not using HCI UART CTS as shown in the schematics. Can you check whether your device is in normal working mode when you observe the issue. Ensure it is not going to recovery mode. Please check the state of SPI2_MOSI as it is used for recovering the device.
Could you share your code with us? We will try to reproduce the error and get back to you our advices.
our production firmware image does not use HCI UART for logging, so we call set wiced_set_debug_uart(WICED_ROUTE_DEBUG_NONE). Do we also need to undefine WICED_BT_TRACE_ENABLE in the makefile?
Recovery pin is ok and the device is in normal working mode.
Today we've found that the problem is present only if we call wiced_sleep_config(WICED_TRUE, ...) thus is correlated to low power mode. Maybe the HCI CTS low prevented the device to go in sleep mode making the PUART work normally?
As a workaround we disabled sleep mode completely when PUART is working, but we're wondering if there is a better approach (via wiced_sleep_configure() ?) because this way the current consuption of our application increases.
We were expecting PUART to work out of the box as other peripherals (radio, HCI UART, timers..) with low power mode enabled. Is there any example showing how to use low power mode with PUART?
OK. So low power mode is also configured in your application. May I know what is the mode you have selected for low power? If you have selected WICED_SLEEP_MODE_TRANSPORT then the device is expected to go to sleep when the CTS is asserted - i.e. Host is connected. So when the sleep changes the power mode, depending upon the power mode behaviour, PUART or other peripherals may go to cutoff state to save power.
It is not usually used PUART in low power mode. But you can use it. Each time you have to wake up the device from the host before you start communicating over PUART. Then transfer the data over PUART. Also sometimes the peripherals (GPIO/PUART/etc.) need to reinitiate or reconfigure when the device wakes up.
to activate low power I call wiced_sleep_config(WICED_TRUE , WICED_WAKE_GPIO_ACTIVE_LOW, WICED_WAKE_GPIO_ACTIVE_LOW).
Where can I set WICED_SLEEP_MODE_TRANSPORT ?
If I understood correctly from
wiced_sleep_config() alone should work. Isn't it?
In my application I do not have an external host. Just using the HCI UART as the trace output for debug purposes (dongle not always connected to the board and CTS left floating).
Using sleep mode with wiced_sleep_config we have a current consuption of about 10mA which is quite high. How can we further reduce it?