Hi!
With STM32Cube_FW_F2_V1.9.0 and CDC's /dev/ttyACM0 I had funny glitches on VoidLinux, when i tried full duplex communication (host<>device):
- some packets never arrived at the USB host
- some short packets had their first 4 byte twice
DeepSeek suggested to choose different endpoints for data in and out... like this:
#define CDC_IN_EP 0x81U /* EP1 for data IN */
#define CDC_OUT_EP 0x02U /* EP2 for data OUT */
#define CDC_CMD_EP 0x83U /* EP3 for CDC commands */
it seems like those glitches disappeared now... Or i did not dare to test it hard enough... :face_savoring_food:
Why is CDC_OUT_EP 0x01U by default, although DeepSeek thinks, that the STM32F207 hardware cannot cope with that, because IN&OUT stream share somehow the same hardware elements, if they are configured for the same endpoint?
It was easy to fix, after i found Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc/usbd_cdc.h , but i wonder now, if i really found the bug...
Seems like i am the only one, who had this problem... On the USB host i use 2 posix threads to read&write to /dev/ttyACM0... And on the USB device I use this:
u8 tx[7+255];
bool usbdTxIdle() {
if (udev.dev_state!=USBD_STATE_CONFIGURED) return false;
USBD_CDC_HandleTypeDef * hcdc = (USBD_CDC_HandleTypeDef*) udev.pClassData;
return hcdc && !hcdc->TxState && !hcdc->RxState;
}
u32 usbdrbx(const u32 rbt, const u32 rbf, u32 l) {
if (l==0) return 0;
if (!usbdTxIdle()) return 0;
if (l>sizeof(tx)-7) l=sizeof(tx)-7;
u64 v=((rbf<<16)|rbt); v<<=(8+16); v|=(l<<16); *(u64*)tx=v;
memcpy(tx+7,rb.b+rbf,l); // rb.b is COBS encoded with a single NUL between messages
USBD_CDC_SetTxBuffer(&udev,tx,7+l);
if (unlikely(USBD_CDC_TransmitPacket(&udev)!=USBD_OK)) return 0;
return l;
}
Thx.
Bye
