summaryrefslogtreecommitdiff
path: root/nuttx/configs/pic32-starterkit
diff options
context:
space:
mode:
authorpatacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3>2012-03-19 17:56:15 +0000
committerpatacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3>2012-03-19 17:56:15 +0000
commit5fac8e83aba8dcd6493d8502783e471c8ddf2be6 (patch)
tree5d423851b7062520785d7624c9a1d0b3a09ce33b /nuttx/configs/pic32-starterkit
parentd1aa52f99c7510c1f515a4cac81bf4fac3083c83 (diff)
downloadpx4-nuttx-5fac8e83aba8dcd6493d8502783e471c8ddf2be6.tar.gz
px4-nuttx-5fac8e83aba8dcd6493d8502783e471c8ddf2be6.tar.bz2
px4-nuttx-5fac8e83aba8dcd6493d8502783e471c8ddf2be6.zip
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
Diffstat (limited to 'nuttx/configs/pic32-starterkit')
-rw-r--r--nuttx/configs/pic32-starterkit/README.txt28
1 files changed, 27 insertions, 1 deletions
diff --git a/nuttx/configs/pic32-starterkit/README.txt b/nuttx/configs/pic32-starterkit/README.txt
index fb693f54e..db3886343 100644
--- a/nuttx/configs/pic32-starterkit/README.txt
+++ b/nuttx/configs/pic32-starterkit/README.txt
@@ -1171,4 +1171,30 @@ Where <subdir> 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