CDC: tud_cdc_write returns 0. How to fix?

[ned-pcs]

I've written a CAN to slcan application for the STM32F072.
It receives CAN packets and writes slcan text data.
If I don't open the /dev/ttyACMx from a program, I can run cangen as fast as I want with no issues.
If I open the same /dev/tty/ACMx with a terminal program, it will run fine for a while, but then tud_cdc_write() returns 0.

When this happens, I see that:

_cdcd_itf[0].tx_ff is full
line_state = 3
_usbd_dev.connected,addressed = 1
_usbd_dev.suspended = 0
ep_status[2][0] and ep_status[2][1] busy=true, stalled=false, claimed=true
_usbd_dev.cfg_num = 1 (mounted)

I've got pcapng traces with both the CAN and the usbmon packets, or I can get a pure usbmon capture if that'd help.
Could someone suggest a way to diagnose and fix this problem?

[duempel]

@ned-pcs it's always a good idea to print TinyUSB logs by setting CFG_TUSB_DEBUG to value 2.

I could imagine that your problem is caused by the USB packet buffer, which is sharing the last 256 bytes with the CAN peripheral (page 858 at ST's reference manual RM0091). I'm not experienced with TinyUSB's STM32 FS drivers, but Line 56 mentions that it should not be used simultaneously with CAN. Maybe there is a way to reduce the used USB buffer size?

[ned-pcs]

Thanks for spotting that! I don't know how to tell TinyUSB how much of the USB buffer it can use, though.

[ned-pcs]

I made a version of my app with the CAN disabled (and sending fake data as fast as possible), and I'm still getting a 0 return value from tud_cdc_write().
This is happening immediately after the successful transmission of 154 characters.
I've verified that the CAN clock is not enabled.
I still see the same state when I get the 0 return value:

_cdcd_itf[0].tx_ff is full
line_state = 3
_usbd_dev.connected,addressed = 1
_usbd_dev.suspended = 0
ep_status[2][0] and ep_status[2][1] busy=true, stalled=false, claimed=true
_usbd_dev.cfg_num = 1 (mounted)

[ned-pcs]

I've entered an issue #761 about this.

[hathach]

Thanks for your attention. I don't think it'll be necessary to do that.
It turns out that what was happening was that there was not quite enough space for a whole message.
I added a check of `tud_cdc_write_available()`, and if that said that there wasn't enough space for a whole message, I did a `tud_cdc_write_flush()`.
That fixed the issue!

Originally posted by @ned-pcs in #761 (comment)