feat: uart break send + detect

[zpg6]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• I have added necessary changes to user code to the latest Migration Guide.
• My changes are in accordance to the esp-rs developer guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

Continuation of #3177 - aiming for 1.0

Testing

Need help with HIL testing

[zpg6]

@bugadani - I added wait_for_break to complete the HIL test but I would intend to use it more as an interrupt handler now that we have Rx event for break detection.

Do you approve of this?

[bugadani]

I think doing both should be fine. This function has lower latency than any interrupt handler would, so it can probably stay and remain useful in this form.

It makes sense to add an UartInterrupt::Break variant.

It would be nice to have a wait_for_break_with_timeout variant, and an async fn wait_for_break_async, too.

[zpg6]

@bugadani - can you tell why this isn't compiling for me?

[bugadani]

ESP32-C2, C3 and H2 don't have GPIO16 and 17

[zpg6]

@bugadani - can you help me understand why my HIL test is failling only on esp32, esp32c6, and esp32h2? Works on others

[bugadani]

My guess is that you need to start waiting for a break condition before you stop sending it.

[zpg6]

My guess is that you need to start waiting for a break condition before you stop sending it.

@bugadani - two fixes I made to get all passing

1. Enabling of the break detection interrupt before first send

wait_for_break method would enable it but would inherently not be able to detect the break condition consistently if sent before enabled. I added an explicit enable_break_detection method, another solution would be to enable this interrupt at start via new param to uart config or by default in the enable_listen_rx.

This resulted in all except c6 and h2 working consistently on HIL, and continued to work with a new "interleaved break detection test" that gave me more confidence the state machine is working well.

2. c6/h2 need sync_regs()

I noticed c6 and h2 require sync_regs() sometimes when you're manipulating registers. Doing sync_regs() on the break detection interrupt enable didn't work. But both started to work when I also did it after inverting the TX line each time for sending break.

[zpg6]

HIL Tests

• test_break_detection - Sends a break and receives it back
• test_break_detection_no_break - Times out when no break
• test_break_detection_multiple - Multiple sequential breaks
• test_break_detection_interleaved - Alternating breaks and timeouts with and without break sent
• test_break_detection_with_data - Break detection mixed with normal data transmission
• test_break_detection_preserves_data - Verifies data integrity when break occurs while there is buffered data

[zpg6]

@bugadani - any idea why esp32 HIL hardware is failing last few builds?

 WARN probe_rs::vendor::espressif::sequences::esp32: Be careful not to reset your ESP32 while connected to the debugger! Depending on the specific device, this may render it temporarily inoperable or permanently damage it.
[2025-11-05T13:25:42Z INFO  xtask::commands::run] Running test 'alloc_psram_tlsf_quad' for 'esp32'
 WARN probe_rs::vendor::espressif::sequences::esp32: Be careful not to reset your ESP32 while connected to the debugger! Depending on the specific device, this may render it temporarily inoperable or permanently damage it.
Error: Could not determine flash size.
Caused by:
    0: An Xtensa specific error occurred.
    1: Xtensa debug module error.
    2: Error reading register 0x45
    3: Register-specific error
[2025-11-05T13:25:43Z INFO  xtask::commands::run] 'alloc_psram_tlsf_quad' done
[2025-11-05T13:25:43Z INFO  xtask::commands::run] Running test 'aes_no_psram' for 'esp32'
 WARN probe_rs::vendor::espressif::sequences::esp32: Be careful not to reset your ESP32 while connected to the debugger! Depending on the specific device, this may render it temporarily inoperable or permanently damage it.
Error: Could not determine flash size.
Caused by:
    0: An Xtensa specific error occurred.
    1: Xtensa debug module error.
    2: Error reading register 0x45
    3: Register-specific error
[2025-11-05T13:25:44Z INFO  xtask::commands::run] 'aes_no_psram' done
[2025-11-05T13:25:44Z INFO  xtask::commands::run] Running test 'esp_radio_has_wifi_ble' for 'esp32'
 WARN probe_rs::vendor::espressif::sequences::esp32: Be careful not to reset your ESP32 while connected to the debugger! Depending on the specific device, this may render it temporarily inoperable or permanently damage it.
Error: Could not determine flash size.
Caused by:
    0: An Xtensa specific error occurred.
    1: Xtensa debug module error.
    2: Error reading register 0x45
    3: Register-specific error
[2025-11-05T13:25:45Z INFO  xtask::commands::run] 'esp_radio_has_wifi_ble' done

(...and so on, all HIL tests fail only on this chip)

[bugadani]

Don't worry about that. probe-rs can't recover the esp32 if it ends up partially flashed when a HIL run is cancelled, or sometimes when the firmware runs into some state that I don't yet know.