RN4678: macOS RFCOMM/SPP reconnect: port opens but no data until restarting bluetoothd

[Hyatt]

Hi all,

I’m debugging an SPP (RFCOMM) reconnection issue between an STM32F767ZI and a Microchip RN4678 module talking over UART (921600 bps, RTS/CTS).
On first pairing/connection, data flows from STM32→Mac as expected. After disconnecting and reconnecting, the Mac can open /dev/cu.RN****, but no data arrives. Running sudo pkill bluetooth on macOS immediately makes data flow again on the next connection. I’d like to avoid any workaround that needs root privileges (e.g., blueutil, killing bluetoothd).

Environment

• macOS: [version, e.g., 14.5 Sonoma / 13.x Ventura] on [Mac model / Apple Silicon or Intel]

• Python: [version]

• RN4678 firmware: [version if known]

• UART: 921600 bps, RTS/CTS enabled

• Profile: Bluetooth SPP (RFCOMM)

What happens

1. Pair and connect → data flows normally via Python script (link below).

2. Disconnect SPP.

3. Reconnect SPP → serial port opens, but RX on Mac stays silent (no bytes).

4. sudo pkill bluetooth on Mac → reconnect → data flows again.

Links (code/config)

• RN4678 configuration (STM32CubeIDE):
  https://github.com/bdaad/RN4678_stm32/blob/main/main_setup_921600_250904.c

• RN4678 communication (STM32CubeIDE):
  https://github.com/bdaad/RN4678_stm32/blob/main/250905_921600.c

• Python SPP receiver (Mac):
  https://github.com/bdaad/RN4678_stm32/blob/main/250905_921600.py

• STM32 board: https://os.mbed.com/platforms/ST-Nucleo-F767ZI/

• RN4678 module: https://www.digikey.com/en/products/detail/microchip-technology/RN4678-V-RM122/14319067

Additional observations (if useful)

• CTS/RTS levels on the STM32 side during the “stuck” state: [e.g., CTS=HIGH (blocked) / LOW].

• Whether closing/reopening the Python serial port or toggling Bluetooth off/on (without sudo) helps: [result].

• Whether reinitializing USART on the STM32 after a reconnect event helps: [result].

Questions

• Is there a known issue or best practice on macOS for fully releasing RFCOMM/SPP state between connections so data flows on reconnect without restarting bluetoothd?

• From the STM32 side, should I explicitly drop/raise RTS, flush UART, or reinitialize USART after link-up to avoid the “silent” state?

• Any recommended RN4678 settings for reliable SPP reconnects with macOS (e.g., SQ, flow control, link timers)?

Any guidance would be greatly appreciated. Thank you!

[Andrew Neil]

Do you have any reason to believe that this is anything to do with the STM32?

Have you tried with just a terminal connected to the RN4678 ?

For support on the RN4678, you need to go to Microchip:

https://www.microchip.com/en-us/support

Microchip Wireless Support Forum

 

---

@Hyatt wrote:

• Is there a known issue or best practice on macOS for fully releasing RFCOMM/SPP state between connections so data flows on reconnect without restarting bluetoothd?

---

Note that ST have no Classic BT products - so Microchip are going to be the best ones to ask about  that

 

---

@Hyatt wrote:

• From the STM32 side, should I explicitly drop/raise RTS, flush UART, or reinitialize USART after link-up to avoid the “silent” state?

---

The RN4678 neither knows nor cares what microcontroller you use - so this would not be specific to STM32.

 

---

@Hyatt wrote:

• Any recommended RN4678 settings for reliable SPP reconnects with macOS (e.g., SQ, flow control, link timers)?

---

That's definitely a question for Microchip - it's their product, so they would know!

[Hyatt]

Thanks Andrew — that clarifies things.

I’ll take this up on the Microchip Wireless Support Forum as you suggest.

Appreciate the pointers and confirmation!