Yes this is the correct behaviour, we need to wait for the 0 byte packet to have been sent before going on. I don't know about the BTABLE entry, although I remember (but couldn't find it in the reference manual) reading somewhere that once a transfer is going on, these BTABLE entries are taboo.

Also I would not do the sending of the 0 byte packet in the interrupt (I tried that at first), because it would send a 0 byte packet after each 64 bytes packet, instead of waiting for the end of the long string of 64 byte packets (in case I send 2kB for example).

I did some eclipse magic, I had the project nested inside our main project, and it would take over the 2 byte indenting. sorry about that (and the sign-offs), I was a bit caught up in the whole coding.

Regards, Manuel

On Jan 17, 2013, at 8:08 PM, Marti Bolivar <notifications@github.com> wrote:

> In libmaple/usb/stm32f1/usb_cdcacm.c:
> 
> > @@ -428,6 +407,11 @@ uint32 usb_cdcacm_tx(const uint8* buf, uint32 len) {
> >          usb_set_ep_tx_count(USB_CDCACM_TX_ENDP, len);
> >          n_unsent_bytes = len;
> >          usb_set_ep_tx_stat(USB_CDCACM_TX_ENDP, USB_EP_STAT_TX_VALID);
> > +    } else {
> > +      usb_set_ep_tx_count(USB_CDCACM_TX_ENDP, 0);
> > +      usb_set_ep_tx_stat(USB_CDCACM_TX_ENDP, USB_EP_STAT_TX_VALID);
> > +      // actually block here waiting for interrupt, even though we sent 0 bytes
> > +      n_unsent_bytes = 1;
> This introduces another bug -- until the interrupt occurs, usb_cdcacm_get_pending() will falsely return 1, instead of 0. Probably what we want is to have usb_cdcacm_tx() check a new bit of state to see if a flush is still waiting, rather than overload the meaning of n_unsent_bytes in this way.
> 
> Incidentally, I don't know if you saw my source code comment in vcomDataTxCb() -- I tried to read the TX count from the appropriate BTABLE entry for the TX endpoint, rather than assuming that all bytes were flushed. But this broke the device: I couldn't send bytes. Do you know why?
> 
> Also, please use 4 space indents.
> 
> —
> Reply to this email directly or view it on GitHub.
> 
>