From dd3b7ed38d320982f1565d5471e8b0ce810f190e Mon Sep 17 00:00:00 2001 From: patacongo Date: Mon, 19 Mar 2012 17:56:15 +0000 Subject: [PATCH] Minor updates for PIC32 USB device driver bugs git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@4497 42af7a65-404d-4744-a932-0658087f49c3 --- configs/pic32-starterkit/README.txt | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/configs/pic32-starterkit/README.txt b/configs/pic32-starterkit/README.txt index fb693f54e2..db38863430 100644 --- a/configs/pic32-starterkit/README.txt +++ b/configs/pic32-starterkit/README.txt @@ -1171,4 +1171,30 @@ Where is one of the following: little testing I have done with it, it appears functional. But the logic has not been stressed and there could still be lurking issues. + Update. The following was added to the top-level TODO list: + Title: PIC32 USB DRIVER DOES NOT WORK WITH MASS STORAGE CLASS + Description: The PIC32 USB driver either crashes or hangs when used with + the mass storage class when trying to write files to the target + storage device. This usually works with debug on, but does not + work with debug OFF (implying some race condition?) + + Here are some details of what I see in debugging: + + 1. The USB MSC device completes processing of a read request + and returns the read request to the driver. + 2. Before the MSC device can even begin the wait for the next + driver, many packets come in at interrupt level. The MSC + device goes to sleep (on pthread_cond_wait) with all of the + read buffers ready (16 in my test case). + 3. The pthread_cond_wait() does not wake up. This implies + a problem with pthread_con_wait(?). But in other cases, + the MSC device does wake up, but then immediately crashes + because its stack is bad. + 4. If I force the pthread_cond_wait to wake up (by using + pthread_cond_timedwait instead), then the thread wakes + up and crashes with a bad stack. + + So far, I have no clue why this is failing. + Status: Open + Priority: High