STM32 UDC: fix transmission on halted endpoints #93796

marwaiehm-st · 2025-07-28T21:21:00Z

Manage endpoint halt state explicitly in set/clear halt functions.
Prevent transmissions on halted endpoints n enqueue function.
Trigger retransmission post-halt clearance if applicable.

Fixes: #91483
This fix is based on the patch by @jfischer-no : #91067 (comment)

jfischer-no · 2025-08-11T13:52:58Z

drivers/usb/udc/udc_stm32.c

The commit message does not look nice. You can have up to 75 characters per line in the commit message.

Manage endpoint halt state explicitly in set/clear halt functions. Prevent transmissions on halted endpoints in enqueue function. Trigger retransmission post-halt clearance if applicable.

jfischer-no · 2025-08-11T13:56:10Z

drivers/usb/udc/udc_stm32.c

+
+		if (buf && USB_EP_DIR_IS_IN(cfg->addr) && !udc_ep_is_busy(cfg)) {
+			udc_stm32_tx(dev, cfg, buf);
+		}


What about the OUT direction? Do you need to restart anything explicitly here? I did not have time to look at the OUT path in my suggestion, so I just added a comment.

Good point regarding the OUT direction. For OUT endpoints, I will add logic to re-arm the endpoint (e.g., by calling udc_stm32_rx()) to ensure it is ready to receive new data.
I’ll update the code accordingly.

etienne-lms

Nitpicking comments.

etienne-lms · 2025-08-12T09:44:50Z

drivers/usb/udc/udc_stm32.c

+	if (USB_EP_GET_IDX(cfg->addr)) {
+		struct net_buf *buf = udc_buf_peek(cfg);
+
+		if (buf && USB_EP_DIR_IS_IN(cfg->addr) && !udc_ep_is_busy(cfg)) {


Suggested change

if (buf && USB_EP_DIR_IS_IN(cfg->addr) && !udc_ep_is_busy(cfg)) {

if (buf != NULL && USB_EP_DIR_IS_IN(cfg->addr) && !udc_ep_is_busy(cfg)) {

etienne-lms · 2025-08-12T09:46:23Z

drivers/usb/udc/udc_stm32.c

+	 * If endpoint is non-control, has pending data, is IN direction,
+	 * and not busy, trigger retransmission to continue data flow
+	 */
+	if (USB_EP_GET_IDX(cfg->addr)) {


Suggested change

if (USB_EP_GET_IDX(cfg->addr)) {

if (USB_EP_GET_IDX(cfg->addr) != 0U) {

etienne-lms · 2025-08-12T09:48:07Z

drivers/usb/udc/udc_stm32.c

+			 * Endpoint is halted (stalled) by the host
+			 * Skip transmission to avoid protocol violations
+			 * and potential data corruption


Prefer with terminal dots to explicitly end each sentences.

Suggested change

* Endpoint is halted (stalled) by the host

* Skip transmission to avoid protocol violations

* and potential data corruption

* Endpoint is halted (stalled) by the host.

* Skip transmission to avoid protocol violations

* and potential data corruption.

nandojve · 2025-08-14T14:53:40Z

Hi @marwaiehm-st ,

Can you confirm that with this patch the /dev/bus/usb/003/083 test 13 --> 22 (error 22) reported on #94001 is fixed ?

marwaiehm-st · 2025-08-18T13:47:54Z

Hi @marwaiehm-st ,

Can you confirm that with this patch the /dev/bus/usb/003/083 test 13 --> 22 (error 22) reported on #94001 is fixed ?

Hi @nandojve ,

In my testing, I observed the following results:

With v4.1.0 (sudo ./testusb -v 512 -D /dev/bus/usb/001/021):

./testusb: /dev/bus/usb/001/021 may see only control tests
high speed	/dev/bus/usb/001/021	0
/dev/bus/usb/001/021 test 0,    0.000008 secs
/dev/bus/usb/001/021 test 9 --> 32 (error 32)
/dev/bus/usb/001/021 test 10 --> 32 (error 32)

With the main branch (sudo ./testusb -v 512 -D /dev/bus/usb/001/022):

./testusb: /dev/bus/usb/001/022 may see only control tests
full speed	/dev/bus/usb/001/022	0
/dev/bus/usb/001/025 test 0,    0.000007 secs
/dev/bus/usb/001/025 test 9,    1.186878 secs
/dev/bus/usb/001/025 test 10,    4.333058 secs

Based on these results, the issue is no longer reproduced on the latest main branch. However, this patch does not resolve the issue; the fix appears to be present in main independently of this patch.

nandojve · 2025-08-18T14:01:36Z

Hi @marwaiehm-st ,

Just to be sure, did you tested high-speed, right ? In the #94001 I provided a sequence that show to pass on all tests for full/high-speed and the only fails is test #13 in high-speed.

marwaiehm-st · 2025-08-18T14:23:14Z

Hi @marwaiehm-st ,

Just to be sure, did you tested high-speed, right ? In the #94001 I provided a sequence that show to pass on all tests for full/high-speed and the only fails is test #13 in high-speed.

@nandojve, yes i tested high-speed using this PR #89866, there are no errors:

sudo ./testusb -v 512 -D /dev/bus/usb/001/034
./testusb: /dev/bus/usb/001/034 may see only control tests
high speed	/dev/bus/usb/001/034	0
/dev/bus/usb/001/034 test 0,    0.000007 secs
/dev/bus/usb/001/034 test 9,    0.623093 secs
/dev/bus/usb/001/034 test 10,    3.154529 secs

nandojve · 2025-08-18T14:36:18Z

Hi @marwaiehm-st ,
Just to be sure, did you tested high-speed, right ? In the #94001 I provided a sequence that show to pass on all tests for full/high-speed and the only fails is test #13 in high-speed.

@nandojve, yes i tested high-speed using this PR #89866, there are no errors:
sudo ./testusb -v 512 -D /dev/bus/usb/001/034
./testusb: /dev/bus/usb/001/034 may see only control tests
high speed	/dev/bus/usb/001/034	0
/dev/bus/usb/001/034 test 0,    0.000007 secs
/dev/bus/usb/001/034 test 9,    0.623093 secs
/dev/bus/usb/001/034 test 10,    3.154529 secs

Hi @marwaiehm-st ,

I noted that I can see only 3 tests in your list and the 13 is not in. Are you enabling all the test list using the
$ sudo sh -c "echo 0x2fe3 0x0009 0 0x0525 0xa4a0 > /sys/bus/usb/drivers/usbtest/new_id" before connect the USB, right ?

I don't want to bother you but I really want to make sure USB is working 100% on the U5A.

Manage endpoint halt state explicitly in set/clear halt functions. Prevent transmissions on halted endpoints in enqueue function. Trigger retransmission post-halt clearance if applicable. Signed-off-by: IBEN EL HADJ MESSAOUD Marwa <[email protected]>

sonarqubecloud · 2025-08-19T14:20:51Z

Please retry analysis of this Pull-Request directly on SonarQube Cloud

marwaiehm-st · 2025-08-19T14:55:35Z

I noted that I can see only 3 tests in your list and the 13 is not in. Are you enabling all the test list using the $ sudo sh -c "echo 0x2fe3 0x0009 0 0x0525 0xa4a0 > /sys/bus/usb/drivers/usbtest/new_id" before connect the USB, right ?

@nandojve, i hadn’t used that command before connecting the device. After applying all the patches you mentioned in the #94001 and then running the command before connecting the USB device, I noticed a difference in the test results. Now, I can see a more complete list of tests, including test 13.
After test 13, there are additional errors. As shown in the screenshot, tests 14 and onwards return errors such as error 110 and error 32.

nandojve · 2025-08-19T16:57:51Z

@marwaiehm-st,

Thank you for looking on this, I really appreciate it.

Yes, usually when a important feature fails, test 13 for instance, many of the remaining can fail because device stay in a bad state. You can then run one by one if you want to check the other tests by add -t NUM argument.

I notice that something changed in mainline that bring a regression in the 14 and 21 in regards to my branch:

HS

sudo ./testusb -D /dev/bus/usb/003/010
./testusb: /dev/bus/usb/003/010 may see only control tests
high speed	/dev/bus/usb/003/010	0
/dev/bus/usb/003/010 test 0,    0.000009 secs
/dev/bus/usb/003/010 test 1,    2.279118 secs
/dev/bus/usb/003/010 test 2,    0.106608 secs
/dev/bus/usb/003/010 test 3,    2.273010 secs
/dev/bus/usb/003/010 test 4,    0.105132 secs
/dev/bus/usb/003/010 test 5,    6.736057 secs
/dev/bus/usb/003/010 test 6,    3.433691 secs
/dev/bus/usb/003/010 test 7,    6.802363 secs
/dev/bus/usb/003/010 test 8,    3.521648 secs
/dev/bus/usb/003/010 test 9,   26.002096 secs
/dev/bus/usb/003/010 test 10,  124.172379 secs
/dev/bus/usb/003/010 test 11,   13.199023 secs
/dev/bus/usb/003/010 test 12,   15.897979 secs
/dev/bus/usb/003/010 test 13 --> 22 (error 22)
/dev/bus/usb/003/010 test 14 --> 22 (error 22)
/dev/bus/usb/003/010 test 17,    2.340603 secs
/dev/bus/usb/003/010 test 18,    0.104134 secs
/dev/bus/usb/003/010 test 19,    2.253868 secs
/dev/bus/usb/003/010 test 20,    0.106504 secs
/dev/bus/usb/003/010 test 21 --> 22 (error 22)
/dev/bus/usb/003/010 test 24,   66.682751 secs
/dev/bus/usb/003/010 test 27,    6.601279 secs
/dev/bus/usb/003/010 test 28,    3.368649 secs
/dev/bus/usb/003/010 test 29,    7.842020 secs

FS

sudo ./testusb -D /dev/bus/usb/003/016
./testusb: /dev/bus/usb/003/016 may see only control tests
full speed	/dev/bus/usb/003/016	0
/dev/bus/usb/003/016 test 0,    0.000006 secs
/dev/bus/usb/003/016 test 1,    1.455110 secs
/dev/bus/usb/003/016 test 2,    1.089137 secs
/dev/bus/usb/003/016 test 3,    1.454560 secs
/dev/bus/usb/003/016 test 4,    1.038891 secs
/dev/bus/usb/003/016 test 5,   43.648289 secs
/dev/bus/usb/003/016 test 6,   43.876548 secs
/dev/bus/usb/003/016 test 7,   43.230232 secs
/dev/bus/usb/003/016 test 8,   43.216235 secs
/dev/bus/usb/003/016 test 9,   25.999817 secs
/dev/bus/usb/003/016 test 10,  121.999336 secs
/dev/bus/usb/003/016 test 11,   12.229619 secs
/dev/bus/usb/003/016 test 12,   15.815451 secs
/dev/bus/usb/003/016 test 13,   37.000380 secs
/dev/bus/usb/003/016 test 14 --> 22 (error 22)
/dev/bus/usb/003/016 test 17,    1.455097 secs
/dev/bus/usb/003/016 test 18,    1.001890 secs
/dev/bus/usb/003/016 test 19,    1.454136 secs
/dev/bus/usb/003/016 test 20,    1.343544 secs
/dev/bus/usb/003/016 test 21 --> 22 (error 22)
/dev/bus/usb/003/016 test 24,   57.998727 secs
/dev/bus/usb/003/016 test 27,   46.545223 secs
/dev/bus/usb/003/016 test 28,   46.544866 secs
/dev/bus/usb/003/016 test 29,    6.000125 secs

So, 13 still failing as expected in the HS and passing in the FS but both 14 and 21 started to fail where:

TEST 14:  1000 ep0out, 1..1024 vary 1024
TEST 21:  1000 ep0out odd addr, 1..1024 vary 1024

You can reproduce above using the https://github.com/nandojve/zephyr/tree/stm/fix_usb_fs_hs_linux_compliance_tests_more_fixes

@jfischer-no ,

Do you know any changes in mainline about ep0 maintenance ?

mathieuchopstm · 2025-09-11T14:03:07Z

Superseded by 95857

marwaiehm-st force-pushed the usb/stm32/msc-ep-halt-recovery branch 2 times, most recently from 6045959 to 8872a8f Compare July 29, 2025 08:19

marwaiehm-st marked this pull request as ready for review July 29, 2025 11:43

zephyrbot added area: USB Universal Serial Bus platform: STM32 ST Micro STM32 labels Jul 29, 2025

zephyrbot requested review from FRASTM, GeorgeCGV, djiatsaf-st, erwango, etienne-lms, gautierg-st, jfischer-no, mathieuchopstm and tmon-nordic July 29, 2025 11:44

zephyrbot assigned erwango Jul 29, 2025

bzhou88 mentioned this pull request Jul 30, 2025

drivers: USB MSC: STM32U585: can't pass Compliance Test by using USB3CV #91483

Closed

1 task

This was referenced Jul 31, 2025

STM32 UDC shim driver does not pass Linux tests (testusb) #93924

Open

drivers: usb: stm32: Fix USB FS/HS linux compliance tests #94001

Open

jfischer-no reviewed Aug 11, 2025

View reviewed changes

etienne-lms reviewed Aug 12, 2025

View reviewed changes

marwaiehm-st force-pushed the usb/stm32/msc-ep-halt-recovery branch from 8872a8f to 027ca86 Compare August 14, 2025 08:25

nandojve self-requested a review August 14, 2025 14:53

marwaiehm-st force-pushed the usb/stm32/msc-ep-halt-recovery branch from 027ca86 to 9f003e7 Compare August 18, 2025 07:37

zephyrbot added the Release Notes To be mentioned in the release notes label Aug 19, 2025

zephyrbot requested a review from cfriedt August 19, 2025 13:45

zephyrbot requested review from jhedberg and kartben August 19, 2025 13:45

marwaiehm-st force-pushed the usb/stm32/msc-ep-halt-recovery branch from 0daa232 to 9f003e7 Compare August 19, 2025 13:55

marwaiehm-st force-pushed the usb/stm32/msc-ep-halt-recovery branch from 9f003e7 to 07c7d16 Compare August 19, 2025 13:57

marwaiehm-st removed the Release Notes To be mentioned in the release notes label Aug 19, 2025

jfischer-no mentioned this pull request Sep 5, 2025

Stm32 usb high speed fixes #89866

Closed

mathieuchopstm mentioned this pull request Sep 11, 2025

drivers: usb: udc: stm32: handle endpoint halt properly #95857

Merged

mathieuchopstm closed this Sep 11, 2025

	if (buf && USB_EP_DIR_IS_IN(cfg->addr) && !udc_ep_is_busy(cfg)) {
	if (buf != NULL && USB_EP_DIR_IS_IN(cfg->addr) && !udc_ep_is_busy(cfg)) {

	if (USB_EP_GET_IDX(cfg->addr)) {
	if (USB_EP_GET_IDX(cfg->addr) != 0U) {

STM32 UDC: fix transmission on halted endpoints #93796

STM32 UDC: fix transmission on halted endpoints #93796

Uh oh!

Conversation

marwaiehm-st commented Jul 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

etienne-lms left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nandojve commented Aug 14, 2025

Uh oh!

marwaiehm-st commented Aug 18, 2025

Uh oh!

nandojve commented Aug 18, 2025

Uh oh!

marwaiehm-st commented Aug 18, 2025

Uh oh!

nandojve commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sonarqubecloud bot commented Aug 19, 2025

Uh oh!

marwaiehm-st commented Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nandojve commented Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mathieuchopstm commented Sep 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

marwaiehm-st commented Jul 28, 2025 •

edited

Loading

nandojve commented Aug 18, 2025 •

edited

Loading

marwaiehm-st commented Aug 19, 2025 •

edited

Loading

nandojve commented Aug 19, 2025 •

edited

Loading