K64F with 0241 ASSERTS on usbc_msc.c about daplink HOT 10 CLOSED

maybe related to this issue: #102

from daplink.

Hi @teetak01, thanks for reporting this. If you could attach logs of this occurring it would be very helpful. Wireshark + USBpcap should allow you to capture this. Also, what do you mean by RESET? Is this a re-enumeration, a msd endpoint reset comment, a Virtual Box reset or something else?

You mention that the device stops communicating. This is only the mass storage drive right? You should still be able to debug over USB with pyOCD and you should be able to see serial data over the serial port. Can you confirm this?

Finally, Virtual Box has some known USB issues. I haven't seen any with mass storage yet, but they are fairly common with the CMSIS-DAP protocol, as Virtual Box will sometimes drop HID packets. A dropped SCSI packet might explain this assert.

from daplink.

could this be related to https://github.com/mbedmicro/CMSIS-DAP/issues/93?

from daplink.

I have only seen dropped packets when using virtual box, so if they aren't using virtual box then https://github.com/mbedmicro/CMSIS-DAP/issues/93 is probably unrelated.

from daplink.

I think teemu did use raspberry with debian,,

from daplink.

No, this was on virtual box. @jupe is thinking about another possibly related issue we have been having on raspberry environment. You can seen some logs from that issue here: http://jira.arm.com/browse/IOTSYST-1146 . (K64F gets stuck in infinite? loop resending number of traces).

@c1728p9 I have to see if I can somehow reproduce this more reliably to get some logs. So far I have seen it a few times, but it may well be also something Virtual Box is causing. But also I do not remember seeing this issue before on Virtualized Ubuntu 14.04, so may also be some Ubuntu-Virtual Box issue.

The latest fail occured while I was running a testcase on K64F with CLI-testing suite. The device was in middle of sending significant amount of traces via serial port and suddenly CLI stopped receiving any data from serial port and the mass storage drive popped open as the ASSERT.TXT file appeared there. The CLI automatically sends a reset to the device when it proceeded to the next testcase and the testcases continued to execute normally from that.

from daplink.

I was now getting that fail few times in a row while re-flashing K64F. After using another K64F for a while, the first one also started to work a bit better (for now). Maybe I have a faulty hardware?

from daplink.

Hi @teetak01, I think it is unlikely to be faulty hardware. The best way to get to the root of this issue would be to capture some USB logs to determine if the assert is from dropped USB packets.

from daplink.

I was able to reproduce this locally and found this assert is incorrectly triggering if a valid mass storage command arrives at the right time. This should be fixed by #219 which updates the assert criteria.

from daplink.

Ah, good to know, forgot about this completely. Thanks @c1728p9

from daplink.