2025-09-11 10:28 PM - last edited on 2025-09-12 2:02 AM by Andrew Neil
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
Pair and connect → data flows normally via Python script (link below).
Disconnect SPP.
Reconnect SPP → serial port opens, but RX on Mac stays silent (no bytes).
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!
2025-09-12 2:01 AM
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!