cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 USB CDC Read Fails on Mac Mini M4 (macOS 15.5)

AZhao.10
Associate II

Recently I’ve been developing a host application on a Mac Mini (Apple M4, Sequoia 15.5) using Xcode. It communicates with a STM32H7 board via USB CDC, using the internal PHY at 12 Mbps. The USB CDC code is auto-generated by CubeMX with all default parameters. The board works perfectly with serial tools on Windows.

When the same board is connected to the Mac Mini, it successfully enumerates two devices: /dev/tty.usbmodem and /dev/cu.usbmodem. Regardless of which one selected to communicate, writing always succeeds and the board receives the data correctly and sends respond back.However, for some reason, the Mac computer “drops” the incoming data—the application’s read() function never gets anything.

I’ve already tried the following combinations:

  • Reading and writing from tty or cu device
  • Blocking and non-blocking reads (including background event-listening methods)
  • Enabling DTR and/or RTS
  • Using third-party libraries like ORSSerialPort

None of them worked. Also tried some serial tools on Mac, no good luck.

To verify it's not a board issue, I also tested with a NUCLEO-H743ZI2 board configured only with a simple USB CDC echo function. It works perfectly on Windows, but on the Mac Mini, the same problem occurs: the serial port can only write, not read.

Has anyone encountered a similar issue? Any help would be greatly appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions
AZhao.10
Associate II

Problem solved.
The issue turned out to be caused by an unfriendly serial tool I downloaded from the Apple Store for testing. Its display format for received data was quite unusual, which initially led me to believe that the serial port on my Mac Mini was faulty.

In addition, I identified a software issue on my own board. A small code change in CDC_Control_HS()—just a simple logic check for USB control commands, with no loops or blocking operations—unexpectedly affected USB communication timing on macOS. I’m still not sure why, since it works flawlessly on Windows.
After removing that code and recompiling, USB CDC now works perfectly on macOS. Strange.

View solution in original post

4 REPLIES 4
FBL
ST Employee

Hi @AZhao.10 

USB CDC software stack in STM32 handles the reception of data automatically using a callback. By implementing a callback function, you can process incoming data. 

To rule out hardware or macOS-specific issues, test with a known working USB CDC device. If the known device works but the STM32 board does not, the issue is likely with the STM32 firmware. 

Sharing minimum firmware to dive into your setup can help as well.

Maybe using a USB protocol analyzer (for Wireshark with USB capture) to compare the communication between the STM32 device and macOS versus Windows. 

Otherwise, did you try to insert an external USB High-Speed hub?

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.


AZhao.10
Associate II

Hi @FBL , thanks for your suggestion. I don’t have a USB protocol analyzer on hand, so currently I can’t compare the communication differences between Windows and the Mac Mini. Just found an old USB 2.0 hub and tried connecting it to the Mac Mini, but there was no change. Both /dev/tty.usbmodem and /dev/cu.usbmodem can be written to, but they don't receive any data. I’ve confirmed that both devices have read & write permissions.

BTW, I also ordered a USB 3.0 hub from Amazon, which should arrive in the next couple of days — I’ll test again then. Thanks!

AZhao.10
Associate II

Problem solved.
The issue turned out to be caused by an unfriendly serial tool I downloaded from the Apple Store for testing. Its display format for received data was quite unusual, which initially led me to believe that the serial port on my Mac Mini was faulty.

In addition, I identified a software issue on my own board. A small code change in CDC_Control_HS()—just a simple logic check for USB control commands, with no loops or blocking operations—unexpectedly affected USB communication timing on macOS. I’m still not sure why, since it works flawlessly on Windows.
After removing that code and recompiling, USB CDC now works perfectly on macOS. Strange.

FBL
ST Employee

Hi @AZhao.10 

USB stacks can have varying levels of tolerance for timing and protocol handling on different OS. macOS, in particular, is known to be sensitive to USB CDC. You could experiment with adding small delays or logging in CDC_Control_HS() to see how it affects communication.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.