Fixed: First frame is getting lost on a USB-CDC device. (#510)

**Issue**

While using `usb_device` and `usbd_serial` crates with `rp2040_hal`, the first frame from the host device is always getting lost. Consecutive frames work just fine.

**Root Cause**
The `LENGTH_0` region of the `EP_BUFFER_CONTROL` register is always reset (0) while waiting for the first frame. After the first frame failure, the poll operation implicitly sets it  to the necessary value (`max_packet_size`) and this clears the problem for the rest of the app execution life time.

The main problem is while resetting and readjustment of the bits needs a step by step operation to avoid potential issues. While doing that and setting `AVAILABLE` bit, the wrong method had been chosen and was invalidating previous changes. Hence the `LENGTH_0` param is reset, too.

**Proposed Solution**
Instead of direct register `write` operation I've used `modify` to keep current bits in the register.

Co-authored-by: Murat Ursavas <mursavas@nebra.com>
This commit is contained in:
Murat Ursavaş 2022-12-04 02:19:06 +03:00 committed by GitHub
parent 2a5b0ce01e
commit dfc790b207
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -307,7 +307,7 @@ impl Inner {
w.length_0().bits(ep.max_packet_size) w.length_0().bits(ep.max_packet_size)
}); });
cortex_m::asm::delay(12); cortex_m::asm::delay(12);
buf_control.write(|w| w.available_0().set_bit()); buf_control.modify(|_, w| w.available_0().set_bit());
} }
} }
} }