cdc_loop example at high speed

[EmbeddedMagic]

Hi, I am using a blue pill with STM32F103 and the cdc_loop example. To evaluate the stability, I have a PC software that sends an 8byte number to the device. The device will echo the number and the PC will compare if TX=RX. Then the PC increments the number by 1 and send again to the device....all this happens at maximum speed. It happens that the device is not echoing after 100...3000 transmission. It seems

static int32_t ep_write(uint8_t ep, void *buf, uint16_t blen) {
...
    /* invalid or not ready */
    default:
        return -1;     <-- 
}

-1 is returned. What could be the route cause of that? Thx a lot for your response!

[GrantMTG]

Maybe you could copy the result to a local variable and see the reason (the value at *reg):

volatile uint16_t *reg = EPR(ep);
switch (*reg & (USB_EPTX_STAT | USB_EP_T_FIELD | USB_EP_KIND))
   :

[EmbeddedMagic]

The mask (USB_EPTX_STAT | USB_EP_T_FIELD | USB_EP_KIND) is 0x0730. reg is pointing to adr. 0x40005C04 which is I guess is register USB_EP1R, ep is 0x81. In good case (_case (USB_EP_TX_NAK | USB_EPBULK):) reg is 0x7061 when entering the case and 0x70A1 when leaving the case.

In bad case (default:) reg is for example 0xA0A1 or 0xE0A1 (breakpoint at return statement) FYI: I use a jLink debugger and can therefore inspect these values.

I also tried resending after -1 is returned in a do-while-loop. This didn't work either, but I need to deep dive more into it. This seems to be the obvious solution.

So Dmitry is from Ukraine? I really hope he is safe. I am of course not in the position to expect any answer from him.

[GrantMTG]

Well, FWIW, I never wrote at that level, I always used usbd_ep_write().

I'm going to hazard a guess that the endpoint isn't ready, try again later... you could implement that and see if the situation resolves if you do retry.

It's probably the middle of the night where Dmitry is and/or the war might be affecting him or his locale.