USB-UART stability issues over STLINK when "Mass Storage" type enabled on MACOS

[Legacy member]

I've found that Nucleo-L4R5ZI and Nucleo-L476RG sometimes stop receiving UART data through the STLINK USB interface is Mass Storage type is enabled.

I created a program that echos random data sizes (send to board, board echos back). This will crash after a while on macOS if "Mass Storage" is enabled (it is fine on Windows and Linux regardless of Mass Storage option). Here is a simple MBED project and both a Python and Node application to cause the failure.

https://github.com/petertorelli/serialbreaker

The crash takes a while to happen, it is quite intermittent, and requires a full uplug/replug of the device (macOS will sometimes complain that the mass device was not removed properly).

I have another where I found the ST board can still transmit, it just cannot receive. I know this because I can reset the board with the reset button, see a boot test message, but it still won't respond to commands sent over the UART. I think the bug is in the RX path from the host to the STM board.

I've seen this on every MacOS version since Mavericks (when I first started developing). I've never seen it on Windows or Linux. I recommend anyone using the dev board in this mode to disable Mass Storage.

--Peter

[Walid ZRELLI]

Hello @Community member​ ,

In order to allow a better analysis of this issue, Could you please provide your UART configuration and your project to reproduce this issue, so that we can give you an answer.

Thanks in advance.

BeST Regards,

Walid

[Legacy member]

Hello @Walid ZRELLI​ ,

I added a CubeMX project to my repo (minus the drivers) and the IOC file for a Nucleo L4R5ZI.

https://github.com/petertorelli/serialbreaker/tree/main/firmware/cubemx/NUCLEO-L4R5ZI

I wrote the code for the MLPerf Tiny firmware framework based on this board, and a number of people encountered the same problem with ST boards but only on macOS. I believe I root caused it to the issue I submitted, but I please try the "breaker" Node/Python code in the repo. E.g.:

% python3 main.py /dev/<portname>

It should run for a while then hang (usually a few minutes). DIsable Mass Storage with the STLink firmware update and it runs overnight. I've seen this issue on multiple macs and os versions.

Thanks,

Peter

[Legacy member]

Hello Walid,

Were you able to reproduce the problem?

Peter

[Walid ZRELLI]

Hello @Community member​ ,

This issue is under investigation. I will keep you updated as soon as possible.

BeST Regards,

Walid

[Walid ZRELLI]

Internal ticket number: 128440 (PS: This is an internal tracking number and is not accessible or usable by customers)

[Walid ZRELLI]

Hello @Community member​ ,

Could you please try removing the locking mechanism (__HAL_LOCK()/__HAL_UNLOCK() )from the HAL_UART_Transmit_IT/Receive_IT() APIs and let me know if this solved your problem?

Thanks in advance.

BeST Regards,

Walid

[Walid ZRELLI]

Hello @Community member​ 

Is there any news from your side?

BeST Regards,

Walid

[Legacy member]

Hello @Walid ZRELLI​ 

I didn't have time to test last week, I will apply your suggestion shortly. Thanks for the follow up!

Peter

[Legacy member · Accepted solution]

Hello @Walid ZRELLI​ ,

When I went to switch the L4R5ZI back to "mass storage device" with the CubeMX programmer, it updated the STLink firmware and now that board is not failing at all.

So I switched to a L476RG.

1. Default mode: out of the box it fails in a matter of seconds
2. Disable LOCK/UNLOCK: I commented out the LOCK/UNLOCK code in Transmit_IT, Receive_IT, and Start_Receive_IT(). I still failed in seconds.
3. Upgrade L476RG: The current firmware that is failing is V2J35M26. I updated to V2J37M27 and left mass-storage enabled, and used the application firmware from step 1 (with lock/unlock intact): it has been running fine for an hour.

It looks like firmware V2J37M27 fixed the problem, as I also tested on two other L476RG board and an F429ZI, and the STLink f/w update solved the crashes.

Thanks for looking into this, I appreciate the support!

Peter