feature(esp_tinyusb): Remote wakeup device test application [WIP]

[roma-jam]

Description

Test application for Remote Wakeup feature on ESP32-S2, ESP32-S3, ESP32-P4 (USB OTG 1.1 and USB OTG 2.0).

Test requires external USB Host, which might be send to sleep mode by an operator.

Logic of the test is linear, all events (ATTACH, SUSPEND, RESUME) are verified and the test simplifies the verification of the feature:

• connect the device to the host
• run the test
• initiate the sleep
• get the result

Possible to run on USB1.1 for S2/S3 and on USB2.0 and USB1.1 for P4.

ESP32-P4 USB OTG 2.0

ESP32-P4, USB OTG 1.1

Related

N/A

Testing

Added additional test:

---

Checklist

Before submitting a Pull Request, please ensure the following:

• 🚨 This PR does not introduce breaking changes.
• All CI checks (GH Actions) pass.
• Documentation is updated as needed.
• Tests are updated or added as necessary.
• Code is well-commented, especially in complex areas.
• Git history is clean — commits are squashed to the minimum necessary.

[Copilot]

Pull Request Overview

This PR introduces a test application for the Remote Wakeup feature on ESP32-S2, ESP32-S3, and ESP32-P4 devices, supporting both USB OTG 1.1 and USB OTG 2.0 interfaces.

Key Changes:

• Implements HID device test cases that verify remote wakeup functionality by suspending the USB device and triggering a wakeup signal followed by a keyboard input.
• Adds test infrastructure including event handling for suspend/resume states and common device test utilities.
• Provides SDK configuration with appropriate TinyUSB settings and disabled watchdogs for interactive testing.

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
sdkconfig.defaults	SDK configuration with TinyUSB HID settings, disabled watchdogs, and comprehensive heap/stack checking
test_remote_wakeup.c	Main test implementation with HID descriptors and two test cases for remote wakeup on different USB OTG ports
test_app_main.c	Test application entry point with ASCII art banner and Unity test runner setup
idf_component.yml	Component manifest specifying esp_tinyusb dependency
device_common.h	Header defining test device event types and utility function declarations
device_common.c	Event handling infrastructure with queue-based event management and TinyUSB callbacks
main/CMakeLists.txt	Component build configuration specifying source directories and dependencies
CMakeLists.txt	Project-level build configuration with minimal build optimization

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull Request Overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cursor]

You have run out of free Bugbot PR reviews for this billing cycle. This will reset on November 20.

To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[Copilot]

Pull Request Overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tore-espressif]

@roma-jam Thank you for preparing this test. Before moving forward, there are several points we should address:

1. Test app structure
   Please analyze whether creating a new test_app is truly necessary for these two new test cases. Could they be integrated into an existing test application instead?
   The motivation is to minimize build and test duration. Each additional test_app increases build time and significantly prolongs on-target testing (due to new artifacts, separate flashing, and setup). In contrast, extending an existing app with two new test cases would have a negligible impact on both build and execution time.

2. Automation and CI integration
   Please add a corresponding pytest_*.py file so these tests can run automatically in CI. This ensures the new functionality is continuously verified and doesn’t rely on manual execution.

3. Reducing operator interaction
   The current test procedure still requires considerable manual action, which makes it unsuitable for automated CI runs.
   Since the USB Host library already supports the suspend feature and Remote Wake-up support is being added, it would be preferable to adapt this test to run fully automated between two ESP boards connected via USB. This approach aligns with how we already execute USB class driver tests and can reuse the existing dual-runner infrastructure.

[tore-espressif]

Why do we need the storage components?

[tore-espressif]

There is no C++ in this project, so this might be redundant?

[roma-jam]

Hi @tore-espressif,

I added this test to verify the Remote Wakeup feature and it just a bit more convenient, rather than use esp-idf example.

Ok, I can keep it locally for now.

Regarding the test refactoring, I already created a ticket with similar task (as we have already shared files).
It is possible to merge most of them into one test application.
I updated it with new information: IEC-324

[tore-espressif]

Ok, I can keep it locally for now.

No, the goal is to have it in CI, running on our dual target runners

[roma-jam]

Hi @tore-espressif,

Yes-yes, I got it.
Also, I don‘t think that this test might be used „as is“ to run it with esp-host.

I realised earlier, that the structure of esp_device test_apps might be optimised.

But after your comment here, I suddenly realised it even more, in the way: „we do not need to build or to have in CI any test apps, that might be run only locally“. And sure, this is true, as why do we need to spend time to build apps, that we do not run..

Earlier, I thought that it is good to have them in the repo, as any of us could run them to test smth anytime.
But that was a wrong idea, as this loads the runners and increases build time.
Every push/change.

I agree, so I‘ll clean them.