[ottf] Investigate USB test failures with alert catching enabled
- Dominant language
- SystemVerilog
- Stars
- 3.6k
- Forks
- 1.1k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 141
Description
### Description
After #27465 was merged, the `usbdev_deep_reset_test` and `usbdev_deep_disconnect_test` begun (relatively) consistently failing on some FPGAs on `earlgrey_1.0.0`, and so I created #27706 to temporarily disable alert catching on these tests to unblock CI.
Further investigation is needed into why the tests are failing in the way they are - I personally do not have any knowledge about the usbdev tests, but what's interesting here is that the tests are failing with the introduction of the alert catching mechanism, despite not failing directly due to an alert being caught. My suspicion is that these tests were already fragile, and the additional OTTF logic caused some failure threshold to be reached, though I have no way to easily confirm this.
The failure for both tests can be seen e.g. [here](). Reproducing the last few lines of errors, for the `usbdev_deep_disconnect_test` (this was seen before, but much less frequently):
```
[2025-07-21T17:52:36.114Z INFO usbdev_suspend] Iteration 1 of 1
[2025-07-21T17:52:36.114Z INFO usbdev_suspend] Test phase DeepDisconnect
[2025-07-21T17:52:36.114Z console]sw/device/tests/usbdev_deep_disconnect_test.c
[2025-07-21T17:52:36.114Z console]I00002 usbdev_suspend.c:1887] Running USBDEV_SUSPEND test
[2025-07-21T17:52:36.115Z console]I00003 usbdev_suspend.c:1898] (seq: DeepDisconnect to Shutdown 1 times without traffic)
[2025-07-21T17:52:36.115Z console]I00004 usbdev_suspend.c:1901] Booting for the first time
[2025-07-21T17:52:36.116Z console]I00005 usbdev_suspend.c:1652] Phase awaiting stimulus
[2025-07-21T17:52:36.116Z INFO usbdev_suspend] suspending port 4
[2025-07-21T17:52:36.120Z INFO usbdev_suspend] suspended
[2025-07-21T17:52:36.171Z INFO usbdev_suspend] Skipping VBUS Disconnection because support unavailable
[2025-07-21T17:52:36.171Z INFO usbdev_suspend] resuming device on port 4
319:Finished test usbdev_suspend: Err(Operation timed out
```
and for the `usbdev_deep_reset_test`:
```
[2025-07-21T17:52:51.082Z console]entry: 0x20010480
[2025-07-21T17:52:51.089Z console]I00001 ottf_main.c:173] Running sw/device/tests/usbdev_deep_reset_test.c
[2025-07-21T17:52:51.098Z console]E00002 usbdev_suspend.c:1186] CHECK-fail: link_state == kDifUsbdevLinkStatePowered || link_state == kDifUsbdevLinkStateDisconnected
[2025-07-21T17:52:51.109Z console]E00003 usbdev_suspend.c:1944] CHECK-STATUS-fail: Internal:["UDU",1186]
[2025-07-21T17:52:51.113Z console]I00004 status.c:34] FAIL!
319:Finished test usbdev_suspend: Err(Failure result: ["FAIL!", "FAIL"]
```
Contributor guide
Research direction
Start with usbdev_deep_reset_test.c and usbdev_deep_disconnect_test.c, then trace the reported failures in usbdev_suspend.c, including the checks around line 1186 and the timeout path. Reproduce both tests on earlgrey_1.0.0 with alert catching enabled and determine why they fail; done means the failures are explained and the tests work without the temporary disabling workaround.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- embedded-iot, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100