Replies: 3 comments 1 reply
-
|
I think I've spotted an issue while on travel, if OUT EP is stalled then cbw should not be queued: tinyusb/src/class/msc/msc_device.c Line 124 in 83fa3bb Just like the check for IN EP: tinyusb/src/class/msc/msc_device.c Line 207 in 83fa3bb |
Beta Was this translation helpful? Give feedback.
-
|
Here my knowledge for usb endpoint state processing is not enough... If you give me an exact lines to patch it - I can try it. But I don't feel good enough to change this code by myself. |
Beta Was this translation helpful? Give feedback.
-
|
I will try it, but after the holidays. Merry Christmas and a Happy New Year! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I found a bug in my code, which provokes a strange behaviour on MSC device driver. I have the following code for tud_msc_write10_cb()
There is bug in my code here:
if((lba + blocks_to_read) < g_usb_prv.msd_block_cnt)
This effectively blocks the writting in last sector of the card (it must be <= instead of <). So the function returns TUD_MSC_RET_ERROR.
Up to here, all is normal, it's my bug. But as soon as it returns TUD_MSC_RET_ERROR, the following ASSERT is rised in usbd_edpt_xfer():
// Attempt to transfer on a busy endpoint, sound like an race condition !
TU_ASSERT(_usbd_dev.ep_status[epnum][dir].busy == 0);
Currently I don't know - is it due to my wrong handling of SCSI write10 error, or it's a bug in the MSC code. But in my head - to return TUD_MSC_RET_ERROR is not a forbiden case, it can happen in real life, so the MSC should react properly. Or maybe I'm wrong?
This is the debug report on level 2.
Beta Was this translation helpful? Give feedback.
All reactions