arch/arm/src/stm32 and configs/stm32f4discovery: Some feeble attempts to communicate with the BT860. Not much progress yet.

arch/arm/src/stm32/stm32_hciuart.c

@@ -319,8 +319,8 @@ static int  hciuart_dma_nextrx(const struct hciuart_config_s *config);
 #endif
 
 static uint16_t hciuart_rxinuse(const struct hciuart_config_s *config);
-static inline void hciuart_rxflow_enable(const struct hciuart_config_s *config);
+static void hciuart_rxflow_enable(const struct hciuart_config_s *config);
-static inline void hciuart_rxflow_disable(const struct hciuart_config_s *config);
+static void hciuart_rxflow_disable(const struct hciuart_config_s *config);
 static ssize_t hciuart_copytorxbuffer(const struct hciuart_config_s *config);
 static ssize_t hciuart_copyfromrxbuffer(const struct hciuart_config_s *config,
               uint8_t *dest, size_t destlen);
@@ -941,11 +941,13 @@ static uint16_t hciuart_rxinuse(const struct hciuart_config_s *config)
  * Name: hciuart_rxflow_enable
  *
  * Description:
- *   Enable software Rx flow control.
+ *   Enable software Rx flow control, i.e., clear the RTS output.  This will
+ *   be seen as CTS on the other end of the cable and the HCI UART device
+ *   must stop sending data.
  *
  ****************************************************************************/
 
-static inline void hciuart_rxflow_enable(const struct hciuart_config_s *config)
+static void hciuart_rxflow_enable(const struct hciuart_config_s *config)
 {
 #ifdef  CONFIG_STM32_HCIUART_SW_RXFLOW
   struct hciuart_state_s *state;
@@ -963,7 +965,7 @@ static inline void hciuart_rxflow_enable(const struct hciuart_config_s *config)
         {
           wlinfo("Enable RTS flow control\n");
 
-          stm32_gpiowrite(config->rts_gpio, true);
+          stm32_gpiowrite(config->rts_gpio, false);
           state->rxflow = true;
         }
     }
@@ -974,11 +976,13 @@ static inline void hciuart_rxflow_enable(const struct hciuart_config_s *config)
  * Name: hciuart_rxflow_disable
  *
  * Description:
- *   Enable software Rx flow control.
+ *   Disable software Rx flow control, i.e., set the RTS output.  This will
+ *   be seen as CTS on the other end of the cable and the HCI UART device
+ *   can resume sending data.
  *
  ****************************************************************************/
 
-static inline void hciuart_rxflow_disable(const struct hciuart_config_s *config)
+static void hciuart_rxflow_disable(const struct hciuart_config_s *config)
 {
 #ifdef  CONFIG_STM32_HCIUART_SW_RXFLOW
   struct hciuart_state_s *state;
@@ -994,7 +998,7 @@ static inline void hciuart_rxflow_disable(const struct hciuart_config_s *config)
         {
           wlinfo("Disable RTS flow control\n");
 
-          stm32_gpiowrite(config->rts_gpio, false);
+          stm32_gpiowrite(config->rts_gpio, true);
           state->rxflow = false;
         }
     }
@@ -1575,9 +1579,15 @@ static int hciuart_configure(const struct hciuart_config_s *config)
    * have broken HW based RTS behavior (they assert nRTS after every byte
    * received)  Enable this setting workaround this issue by using software
    * based management of RTS.
+   *
+   * Convert the RTS alternate function pin to a push-pull output with
+   * initial output value of zero, i.e., rx flow control enabled.  The HCI
+   * UART device should not send data until we assert RTS.
    */
 
-  pinset = (config & ~GPIO_MODE_MASK) | GPIO_OUTPUT;
+  regval = GPIO_MODE_MASK | GPIO_PUPD_MASK | GPIO_OPENDRAIN |
+           GPIO_OUTPUT_SET | GPIO_EXTI;
+  pinset = (config & ~regval) | GPIO_OUTPUT;
 #endif
   stm32_configgpio(pinset);
 
@@ -1650,6 +1660,9 @@ static int hciuart_configure(const struct hciuart_config_s *config)
                  (void *)config, true);
 #endif
 
+  /* Disable Rx flow control, i.e, assert RTS. */
+
+  hciuart_rxflow_disable(config);
   return OK;
 }
 

configs/stm32f4discovery/README.txt

@@ -1203,6 +1203,26 @@ Configuration Sub-directories
        changed by modifying the disambiguation definitions in
        configs/stm32f4discovery/include/board.h
 
+       I have been testing with the DVK_BT960_SA board via J10 as follows:
+
+         DVK_BT860-SA J10     STM32F4 Discovery P1
+         pin 1  GND                             P1 pin 49
+         pin 2  Module_RTS_O  USART3_CTS PB13,  P1 pin 37
+         pin 3  N/C
+         pin 4  Module_RX_I   USART3_TXD PB10,  P1 pin 34
+         pin 5  Module_TX_O   USART3_RX  PB11,  P1 pin 35
+         pin 6  Module_CTS_I  USART3_RTS PB14,  P1 pin 38
+
+    3. Due to conflicts, USART3 many not be used if Ethernet is enabled with
+       the STM32F4DIS-BB base board:
+
+         PB-11 conflicts with Ethernet TXEN
+         PB-13 conflicts with Ethernet TXD1
+
+       If you need to use the HCI uart with Ethernet, then you will need to
+       configure a new U[S]ART and/or modify the pin selections in
+       include/board.h.
+
   ipv6:
   ----
     This is another version of the NuttShell configuration for the

configs/stm32f4discovery/hciuart/defconfig

@@ -1,6 +1,7 @@
 # CONFIG_ARCH_FPU is not set
 # CONFIG_MMCSD_MMCSUPPORT is not set
 # CONFIG_MMCSD_SPI is not set
+# CONFIG_NET_ETHERNET is not set
 # CONFIG_NET_IPv4 is not set
 # CONFIG_NSH_ARGCAT is not set
 # CONFIG_NSH_CMDOPT_HEXDUMP is not set

configs/stm32f4discovery/include/board.h

@@ -265,6 +265,16 @@
  *
  * Used in pseudoterm configuration and also with the BT860 HCI UART.
  * RTS/CTS Flow control support is needed by the HCI UART.
+ *
+ * There are conflicts with the STM32F4DIS-BB Ethernet in this configuration
+ * when Ethernet is enabled:
+ *
+ *   PB-11 conflicts with Ethernet TXEN
+ *   PB-13 conflicts with Ethernet TXD1
+ *
+ * UART3 TXD and RXD are available on CON4 PD8 and PD8 of the STM32F4DIS-BB,
+ * respectively, but not CTS or RTS.  For now we assume that Ethernet is not
+ * enabled if USART3 is used in a configuration with the STM32F4DIS-BB.
  */
 
 #define GPIO_USART3_TX   GPIO_USART3_TX_1     /* PB10, P1 pin 34 (also MP45DT02 CLK_IN) */