cancel
Showing results for 
Search instead for 
Did you mean: 

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

Hyatt
Associate II

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)

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!

1 REPLY 1
Andrew Neil
Super User

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!

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.