Repository navigation
Replies: 4 comments 3 replies
|
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 |
|
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. |
|
I will try it, but after the holidays. Merry Christmas and a Happy New Year! |
|
Sorry for the delay. The management of our company postponed my project, so I'm currently working on a different one. Anyway - I tried your patch. I'm confirming - it works as I expecting. |
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.
All reactions