Hi,
It looks like you didn't add the dump_stack() call to the UDC driver's
queue function. You need to add it.
The attached is the log of dump_stack() call in the UDC driver queue
function, for the last few USB request in the USBCV device descriptor
test – addressed state. From the log, after
Hi,
The text capture is incomplete. It is missing lots of packets. In
particular, it is missing all the packets between 202489 and 202502.
The missing packets are NAK, I added the NAK after Set-Config setup
stage. I hide the NAK when i export the packet capture to text format.
Also, I
Hi,
Victor, if you can get hold of a USB bus analyzer, you would be able to
see directly when the DATA1 packet does or does not get sent.
I am in the process of getting a USB bus analyzer.
No -- the problem is that the UDC completes the Set-Config request
before it should. In other words,
Hi,
However, the USB-2 spec says (section 9.2.6.4) that devices should be
able to carry out requests with no Data stage (such as Set-Config)
within 50 ms. Does your gadget really take longer than that to handle
the exception?
To find out, collect a usbmon trace showing what happens when
Hi,
May i know which part of the do_set_config() or do_set_interface() has
to be run in process context?
Well, it's not exactly true that the routine has to run in process
context. More accurately, it has to run at a time when the main thread
isn't using any of the endpoints or request
Hi,
However, the USB-2 spec says (section 9.2.6.4) that devices should be
able to carry out requests with no Data stage (such as Set-Config)
within 50 ms. Does your gadget really take longer than that to handle
the exception?
To find out, collect a usbmon trace showing what happens when
Hi,
Yes, this should be the root cause. For the setup stage of Set-Config
request, the UDC driver can handle it well. But for the status stage
of Set-Config request, somehow it is not handled correctly. When UDC
driver receives the endpoint 0 IN token, it only clears the interrupt
request.
Hi,
I can't tell what's going on in your log. Look at the
FSG_STATE_CONFIG_CHANGE case in handle_exception(). Here's the code:
rc = do_set_config(fsg, new_config);
if (fsg-ep0_req_tag != exception_req_tag)
break;
if
Hi,
Than either there is a bug in the UDC (or the UDC driver), or else the
host doesn't wait for the Set-Config request to complete before sending
the next request. What were the values of fsg-ep0_req_tag and
exception_req_tag?
From the printk added, the values of fsg-ep0_req_tag and
Hi,
No, that's not right. Set-Config has only two stages, Setup and
Status; there is no Data stage. The flow is:
Host Device
- Setup Packet --- |
- Data0 Packet --- |== Setup stage
Ack Packet -- |
- In Packet -- |
Hi,
No, i don't see that (Set-Config request with a config value of 0)
Well, then I don't know where the problem is, but obviously the problem
occurred before the gadget driver was involved. Either the host sent a
wrong packet, or more likely the UDC received the packet incorrectly.
Yes,
Hi,
No, i don't see that (Set-Config request with a config value of 0)
Well, then I don't know where the problem is, but obviously the problem
occurred before the gadget driver was involved. Either the host sent a
wrong packet, or more likely the UDC received the packet incorrectly.
Yes,
Hi,
Yes, UDC driver has bug. After modifying it, it can receive Set-Config
request with a config value of 0. However, the device descriptor test
- addressed state still fails.
Please see the attached log. The Set-Config request with a config
value of 0 is the second last USB request sent
Hi,
g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration
Yes, that is a Set-Config request with configuraiton value 1. You
probably got hold of the wrong part of the log. Elsewhere there should
be a Set-Config request with
Hi,
You should not be concerned about variables in the gadget driver. The
problem is in the UDC driver.
For some examples of what the UDC driver needs to do, look at
handle_control_request() in drivers/usb/gadget/dummy_hcd.c or the
switch (u.r.bRequest) statement of handle_stat0_irqs() in
Hi,
I re-attach the usbmon log. If possible, please show me which line
indicates that usb_ep_set_wedge routine is not working, or how to look
for the clue. Is it from the control transfer line?
Here's an example:
f4148f80 308532 S Bo:1:011:1 -115 31 = 55534243 0600 c000
Hi,
The problem is in UDC driver. i made the change, it is ok now.
Good. I noticed that the usb_ep_set_wedge routine still isn't working
right. You might try to fix that.
Alan Stern
Ok, is the usb_ep_set_wedge routine not working? I can't see that in
the log file.
Now, in USB 2.0 CV
Hi,
Ok, is the usb_ep_set_wedge routine not working? I can't see that in
the log file.
It is not working. This can be seen in the usbmon log.
I re-attach the usbmon log. If possible, please show me which line
indicates that usb_ep_set_wedge routine is not working, or how to look
for the
Hi,
Yes, i see the bad characters in the log file. I apologize for that,
my eyes was in pain after looking thru the log files and did not
notice that when i attached the log file.
The good news is i can get gadget to work with Lenovo x100e on Ubuntu
and Windows. The change is adding more
Hi,
There is a mistake in the previous log file, because the fifo size is
still set to 512 byte. Now i change it to 64 byte if it is Full speed.
The FIFO size should always be set to the value in the endpoint
descriptor, no matter what speed the connection is.
The log file are attached.
Hi,
I did another usbmon capture from the moment usb cable is plugged into
the Ubuntu x100e laptop. This time the usbmon does not have -75 error.
When the SCSI_READ_10 command request for 4096 bytes of data, and the
data is returned by the gadget, usbmon simply shows -108 error. The
gadget
Hi,
The usbmon trace shows lots of errors. All those -75 (EOVERFLOW)
status codes mean that the gadget sent a packet that was too large,
i.e., more than 512 bytes. This happened in all the READ(10) commands
except the last one -- none of them succeeded in transferring any data.
After the
Hi,
The hardware handles Set Address request, and i can see the address of
the USB gadget being shown in Windows host. Here i attach the gadget
driver log for the Device Descriptor Test - Addressed State. The
test just failed after Get Configuration request.
I can't tell what's wrong. You
Hi,
Another possibility is to set up a virtual Windows system inside your
Linux host. Then try running the USB CV program on the virtual
machine, and use usbmon on the host system to capture the USB traffic.
I don't know if that will work, but it might.
Thanks. i will find a way to setup
Hi,
Thanks a lot. i understand this part now. Do you notice the Set
Address request is not seen by the gadget driver? The Set Address
request is handled by the hardware. Could it be the root cause? As
gadget driver may expect the address information from the host, and
for now UDC driver just
Hi,
The CV log is attached (Dev_desc_test-Address state.html). Is it helpful?
It doesn't help very much. Can you get a more verbose log, one that
lists all the transfers?
It looks like the problem could be that the host and the gadget don't
agree on what packets have been sent and
Hi,
When i run USB 2.0 Command Verifier on file gadget and UDC driver, an
error in Command Verifier says Device must support being set to
Addressed/Configured state. Does it mean the gadget cannot support
putting device in addressed state or configured state, as in
supporting the Set
Hi,
On Thu, May 30, 2013 at 10:44 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 30 May 2013, victor yeo wrote:
I tested the g_zero with USB 2.0 Command Verifier. After the Command
Verifier is run, the UDC gadget driver queue function is continuously
being called, and the linux
Hi,
Ok. What other gadget driver can i test with UDC driver? Is it the
mass storage driver (mass_storage.c)?
That is essentially the same as g_file_storage. But there are lots of
others. You should start with g_zero and run the testusb suite. See
http://www.linux-usb.org/gadget/
Hi,
Is it possible to
contribute the code to Linux community?
Yes. But first you should test it with other gadget drivers, not just
g_file_storage.
Ok. What other gadget driver can i test with UDC driver? Is it the
mass storage driver (mass_storage.c)?
Has the g_file_storage passed the USB
Hi,
Yes, it is silly. The hardware interrupt is not being generated for
every SCSI command received, so the driver has to poll. I put the
polling code in a thread, and this dilemma is fixed.
Are you sure about this? If it is correct, you should _fix_ the
interrupt problem. Don't try to
Hi,
I am able to solve the SCSI command timeout problem by adding a code
to check the hardware register busy bit continuously, in
kagen2_ep_queue():
do {
read_hardware_register_busy_bit
} while (hardware_is_busy)
This is silly. Drivers shouldn't poll in this way. That's what
Hi,
Thanks! Indeed, the req-buf pointer was the one causing the crash
problem. It happened when combining multiple 512 bytes data. I have
fixed this bug.
Now my UDC driver is almost ready. That is probably one more SCSI
command timeout problem remaining, i am adding more printk to UDC
Hi,
When copying a file to the USB gadget, sometimes the USB gadget will
hang, sometimes the USB gadget will crash, sometimes the copy is ok.
From the UDC driver log, when the USB gadget crashes, the host is
sending 16384 bytes of data. It seems that bulk_out_complete() is not
able to
Hi,
Another question from the bulk_out_complete() printout which is shown
below. The req-actual is 512 byte. The bh-bulk_out_intended_length
is 31. Is this a bug?
g_file_storage gadget: get_next_command
[start_transfer] 6f007442 7000
ept1 out queue len 0x200, buffer 0xc133
Hi,
All I can tell is that the gadget got hung after receiving the second
WRITE command. Can you figure out where it got hung and why?
Victor, you don't seem to get the big pattern that keeps repeating
here. Every time something does wrong, you tell me about it. Then I
point out that you
Hi,
Thanks. I will add more printk statements gradually. Now i discover if
i write to a large text file ( 48k) on USB gadget, linux will crash.
The full log of UDC and gadget driver when linux crashes, and
corresponding usbmon trace are attached. If these logs are not
helpful, i shall add
Hi,
Ok, i just fixed the last three bytes in the bulk-out transfer
problem. Please see below for the log. Now the last three bytes are
read correctly. After SCSI_WRITE_10 is received, the gadget driver
prints g_file_storage gadget: disconnect or port reset, it means USB
reset interrupt is
Hi,
Obviously this disconnect or port reset message is related to the
EP1 OUT IRQ 0x28 line above. But why? It looks like another bug.
I see you still haven't fixed the last three bytes in the bulk-out
transfer.
Ok, i just fixed the last three bytes in the bulk-out transfer
problem.
Hi,
That's right. Interrupts can occur at almost any time (on
multiprocessor systems they can occur even when interrupts are disabled
on some of the CPUs).
I am confused. I add the spinlock functions to kagen2_ep_queue function.
spin_lock_irqsave(dev-lock, flags);
..
Hi,
It is likely that this bug occurs because you don't use a spinlock in
kagen2_ep_queue. Does the interrupt handler routine use a spinlock?
Spinlock is Not used in interrupt handler routine.
Then that's the reason for this bug.
[start_transfer] 53425355 10d
ept1 out queue len 0x200,
Hi,
How the UDC driver know when the request is really complete?
An OUT request is really complete when either:
The total number of bytes copied into req.buffer (i.e.,
req.actual) is equal to req.length, or
The number of bytes received in the last packet is smaller
Hi,
I made some changes regarding req.actual. Now the UDC driver still
cannot process SCSI_WRITE_10 command. Please see the attached UDC
driver log when i try to write to a text file. There should be three
SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and
SCSI_WRITE_10.
Hi,
Please see the attached kagen2_ep_queue(). As long as it is called, it
will queue the request and read packets from hardware, in the same
if-else branch for bulk out endpoint. The interrupt handler will NOT
accept packet if request is NOT queued. If request is queued,
interrupt handler
Hi,
This is the stack dump when the completion routine is called without
an interrupt occurring first, is it useful?
Backtrace:
[c020c0fc] (dump_backtrace+0x0/0x110) from [c03ef5e4]
(dump_stack+0x18/0x1c)
r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8
[c03ef5cc] (dump_stack+0x0/0x1c)
Hi,
Yes, the kagen2_ep_queue() calls req-req.complete directly. I thought
this is necessary to pass the packets to gadget driver for processing?
It is necessary to call req.complete when the request has _completed_!
That's why the callback is named complete!
req-req.complete is mapped to
Hi,
While kagen2_ep_queue() is running, there shouldn't be any packets in
the USB hardware. The hardware should refuse to accept any packets,
sending NAKs back to the host, until a request has been submitted and
queued.
When the request is queued, that's when you should tell the hardware
Hi,
I change that in UDC driver queue function, adding in a length check:
if (len 0)
{
ka_req-req.complete(ka_ep-ep,
ka_req-req);
list_del_init(ka_req-queue);
Hi,
Here is a full log from the beginning which shows another problem.
When the SCSI_READ_10 command below is received, there is a disconnect
or port reset which causes the (-32) broken pipe problem.
You really need to fix the old problems before worrying about new
problems. The set_halt
Hi,
I modified the UDC driver to send out zero length data packet. Now the
linux host is able to see the USB gadget as a mass storage device and
read from USB gadget. However, writing to USB gadget fails. The
SCSI_WRITE_10 command often receives (-104). The usbmon trace showing
this failure
Hi,
From the usbmon trace and driver log, i can only see that TEST UNIT
READY command is sent out but UDC driver does not receive it. May i
ask, under what circumstances, is gadget driver calling
start_transfer() to schedule reading from bulk-out endpoint ?
file_storage.c calls
Hi,
I think the get_next_command() calls start_transfer() to read the next
CBW. After unknown command 0xa1 is received, and if UDC driver doesn't
halt the endpoint, why the get_next_command() does not call
start_transfer() to read the next CBW? Somehow, i don't understand.
I think that the
Hi,
Here are another problem. In usbmon trace, the time difference
between first SCSI_INQUIRY command and the second TEST_UNIT_READY
command is large. So i check the driver log file. When SCSI_INQUIRY is
received, start_transfer() is called, then UDC ep_queue function is
called, then
Hi,
Thanks, i print out additional information in gadget driver and UDC
driver. Here are another problem. In usbmon trace, the time difference
between first SCSI_INQUIRY command and the second TEST_UNIT_READY
command is large. So i check the driver log file. When SCSI_INQUIRY is
received,
Hi,
I use kernel 3.4.4, the code in handle_stat1_irqs() is as below. There
is no reset or disconnect member function in struct
usb_gadget_driver in kernel 3.4.4.
if (stat (1 SUSPEND_REQUEST_INTERRUPT)) {
if (dev-driver-suspend)
Hi,
Thanks for the detailed write-up. I have checked the UDC driver
set_halt(), it is called by the gadget driver. The full ascii text of
usbmon trace for one usb session is also attached. This usbmon trace
shows a few EOVERFLOW(-75) error. I don't know why EOVERFLOW error
happened.
Hi,
Earlier, i used file=/dev/mmcblk0p1. Now i use
file=/mnt/sd/backing_file. This backing_file is a dummy file system
that i created. I attached two jpeg files. One show the MBR and Boot
Sector of the backing_file. Another shows the usbmon of the Linux Host
Why did you send jpeg files?
Hi,
Now i insmod g_file_storage gadget with file=/mnt/sd/backing_file, the
SCSI_READ_10 command is still not working properly.
What makes you think that?
Because the SCSI_READ_10 is able to read the MBR from the backing
file, and after that, SCSI_READ_10 reads all zeroes (fails to read
boot
Hi,
the parameter is file=/dev/mmcblk0p1
Perhaps you have already realized this... mmcblk0p1 is the first
partition of the mmcblk0 device. Block 0 of the partition is the boot
sector, not the MBR. The MBR is block 0 of the mmcblk0 device. So
perhaps you really meant to use:
Hi,
It looks like the data is wrong, but I have no way of knowing what the
data actually should be. Only you know that.
f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
8a28 0008 00
f31a9740 4037054176 C Bo:2:071:1 0 31
f4a555c0
Hi,
the parameter is file=/dev/mmcblk0p1
Perhaps you have already realized this... mmcblk0p1 is the first
partition of the mmcblk0 device. Block 0 of the partition is the boot
sector, not the MBR. The MBR is block 0 of the mmcblk0 device. So
perhaps you really meant to use:
Hi,
the parameter is file=/dev/mmcblk0p1
Perhaps you have already realized this... mmcblk0p1 is the first
partition of the mmcblk0 device. Block 0 of the partition is the boot
sector, not the MBR. The MBR is block 0 of the mmcblk0 device. So
perhaps you really meant to use:
Hi,
Here is the fresh usbmon trace. Four SCSI commands are shown. The
first SCSI_READ_10 command has LBA of 0. The second SCSI_READ_10
command has LBA of 0x00ed2900, which is wrong. Somehow, the first
SCSI_READ_10 command got the wrong data, i think. Isn't it?
It looks like the data is
Hi,
It looks like the data is wrong, but I have no way of knowing what the
data actually should be. Only you know that.
f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
8a28 0008 00
f31a9740 4037054176 C Bo:2:071:1 0 31
f4a555c0
Hi,
Thanks. Working on this problem now. Another problem observed for
SCSI_READ_10 command, when reading from the SD card, the gadget driver
never sends the MBR address, the FAT boot record address, the start of FAT
address, and the start of FAT cluster address to the SD card driver.
The
Hi,
Thanks. Working on this problem now. Another problem observed for
SCSI_READ_10 command, when reading from the SD card, the gadget driver
never sends the MBR address, the FAT boot record address, the start of FAT
address, and the start of FAT cluster address to the SD card driver.
The
Hi,
Here is the gadget log when receiving SCSI_READ_10 from Linux host.
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 0f 00 00 00 00 10 00 00 80 00 0a 28
0010: 00 00 00 00 00 00 00 08 00 00 00 00 e0 f8 02
SCSI CDB: 28 00 00 00 00 00 00 00 08 00
g_file_storage
Hi,
Understand, UDC driver will call driver-setup(), and if the return
value is negative, UDC driver has to set dev-protocol_stall = 1 and
maybe call usb_ep_set_halt(). However, the hardware won't be able to
send out zero length response.
Don't be silly; of course it can. Nobody would be
Hi,
In the log file, is there any invalid request received on endpoint 0?
In the usbmon file there is. It is this line:
f4ae6f40 1217192721 S Co:2:018:0 s 21 ff 0
ok, i will add code to UDC to instruct hardware to send NAK upon
receiving invalid request on endpoint 0.
Hi,
ok, i will add code to UDC to instruct hardware to send NAK upon
receiving invalid request on endpoint 0. Does it mean that UDC driver
has to check for invalid request on endpoint 0?
No. The UDC driver has no way to know whether a request is valid or
not. Read the description of
Hi,
I have a serial console to access the platform. Today i use Linux as
USB host. The log of the usb gadget is attached (gadget-log.txt).
The Linux usbmon log file is also attached (usbmon-log.txt). Hopefully
the log data will be useful.
It looks like you cut out a lot of information from
Hi,
First you have to figure out why it isn't working. What does the
debugging information show?
Here is some debugging information:
receive GET_DESCRIPTOR, 80, 6 index 0 value 200 len 20
receive SET_CONFIGURATION, 0, 9 index 0 value 1 len 0
set curlun-unit_attention_data to
Hi,
On Wed, Mar 20, 2013 at 10:22 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 20 Mar 2013, victor yeo wrote:
Thanks, i add processing the pending data from FIFO after queue was
called. The UDC driver can process the SCSI INQUIRY command and SCSI
READ FORMAT CAPACITIES command now
Hi,
On Fri, Mar 15, 2013 at 01:59:30PM +0800, victor yeo wrote:
For bulk transfer, the new UDC driver has one problem. When SCSI
Inquiry command is received, the UDC driver interrupt routine will
receive it first. However, the queue function is not yet called, and
queue buffer is not yet
Hi,
For bulk transfer, the new UDC driver has one problem. When SCSI
Inquiry command is received, the UDC driver interrupt routine will
receive it first. However, the queue function is not yet called, and
queue buffer is not yet added. Thus, interrupt routine is not able to
store the SCSI Inquiry
Hi,
Thanks, i added in UDC driver to call bulk_in_complete for every
request over a bulk in ep, now the gadget driver is able to process
UDC shouldn't call bulk_in_complete() directly, you should be calling
request-complete() instead.
Yes, the UDC driver calls the request-complete() which
Hi,
Thanks, i added in UDC driver to call bulk_in_complete for every
request over a bulk in ep, now the gadget driver is able to process
the SCSI Inquiry command. When it comes to SCSI Read Format Capacities
command, the gadget driver gives attention condition error in
check_command() in the
Hi,
How to set bh-state to BUF_STATE_EMPTY after the buffer is processed?
It gets set to BUF_STATE_EMPTY in several different places, depending
on the purpose the buffer was used for. See bulk_in_complete (your UDC
driver should call this routine for every request over a bulk-IN
endpoint,
Hi,
How to set bh-state to BUF_STATE_EMPTY after the buffer is processed?
It gets set to BUF_STATE_EMPTY in several different places, depending
on the purpose the buffer was used for. See bulk_in_complete (your UDC
driver should call this routine for every request over a bulk-IN
Hi,
In the udc driver, i can't assign a single ep0 descriptor to both
ep0_in_desc and ep0_out_desc. i think i should skip ep0_out_desc. Bear
in mind that i only define 3 endpoints in udc driver: ep0, ep1 bulk
in, ep1 bulk out. Will it cause any problem to gadget driver?
There is no such
Hi,
When ep1 receives CBW data, the isr routine is called. Then in isr, to
get the usb_request:
usb_request * req;
req = list_entry(dev-ep[2].queue.next, struct kagen2_request, queue);
however, the list_empty(dev-ep[2].queue) is true. Where is the
appropriate place to add list entry?
Hi,
i have list_add_tail() in my ep_queue() function. Prior to ep1
receiving data, my ep_queue() is called to send 0x00 to ep0. then it
is not called. how to make it to be called by file gadget, in order to
queue the request before ep1 interrupt?
This should happen when get_next_command()
Hi,
Also, you shouldn't requeue the request yourself, gadget driver owns the
request.
which request do i requeue? please kindly point that out. Thanks!
look at your code. Look what you do after you call complete.
is it this code? i will remove the redundant code after complete.
Hi,
is it this code? i will remove the redundant code after complete.
ka_ep_p-req.complete(ka_ep_p-ep, req-req);
if (num == 0) {
ka_ep_p-req.length = 0;
usb_ep_queue(ka_ep_p-ep, req-req, 0);
ka_ep_p-desc = ep0_in_desc;
Hi,
i do not see where req-length is checked in gadget
driver.
It isn't _checked_; it is _set_ in set_bulk_out_req_length().
req-actual is checked in received_cbw().
g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration
Hi,
Ok, rephrase the question, is this the flow for bulk transfer?
1) data is received by Usb mass storage HW, the UDC driver ISR is
called to read the data to usb_request buffer
2) bulk_out_complete() in gadget driver, is called to set buffer state
to full
3)
Hi,
In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and
intr_in. Why is the intr_out endpoint not defined?
because it's not needed. Read the USB Mass Storage Class specification
from usb.org
Ok. In the gadget driver, it keeps on receiving the same bulk_out
data, maybe
Hi,
Ok. In the gadget driver, it keeps on receiving the same bulk_out
data, maybe because the data is not processed. The get_next_command is
not called.
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12
0010: 00 00 00 24 00 00
Hi,
In my udc driver, i set the req-length to the number of bytes i
received from HW, which is 31 bytes. Is it necessary to do that? How
you shouldn't touch req-lenght, you should only update req-actual.
req-length is readonly for the UDC.
to know the gadget driver queued 0-bytes?
Hi,
Here are the last two setup data and CBW data received. the
get_next_command() is not called when CBW data is received. the
bulk_out_complete() wakes up the thread, however, get_next_command()
still sleeps. i do not see where req-length is checked in gadget
driver.
g_file_storage
Hi,
Here are the last two setup data and CBW data received. the
get_next_command() is not called when CBW data is received. the
bulk_out_complete() wakes up the thread, however, get_next_command()
still sleeps. i do not see where req-length is checked in gadget
driver.
Hi,
Is there any way to to further debug into why do_scsi_command() is not
called?
usbmon, printk(), trace_printk(), kernel function tracer, there are many
ways choose one and spend some time debugging, I'm sure you'll find the
bug.
It sounds like the UDC driver now works okay
Hi,
It sounds like the UDC driver now works okay for control transfers but
not for bulk transfers.
Some code in file_storage.c that i cannot understand. In
ep0_complete(), the code snippet:
if (req-status == 0 req-context)
((fsg_routine_t)
Hi,
Ok, rephrase the question, is this the flow for bulk transfer?
1) data is received by Usb mass storage HW, the UDC driver ISR is
called to read the data to usb_request buffer
2) bulk_out_complete() in gadget driver, is called to set buffer state to
full
3) get_next_command() in
Hi,
ep0_complete() should be called by your UDC driver. Seriously dude, read
the documentation and read other drivers to figure out how things should
be called. A quick look in the storage drivers would have shown you that
ep0_complete() is passed in as req-complete() through the
Hi,
Yes, ep0_complete() is called in UDC driver queue function, i just
added it in and ep0_complete() is called now. The dmesg output is
below.
not in queue function, you should call it when completing.
Is there any mistake in my understanding of ep0 setup data processing?
1. usb
Hi,
Yes, ep0_complete() is called in UDC driver queue function, i just
added it in and ep0_complete() is called now. The dmesg output is
below.
not in queue function, you should call it when completing.
Is there any mistake in my understanding of ep0 setup data processing?
Hi,
Is there any mistake in my understanding of ep0 setup data
processing?
1. usb gadget HW IRQ is triggered if ep0 receives data
2. fsg_setup() is called
3. ep0_queue() is called
4. UDC driver queue function is called
5. UDC driver sends data to ep0 HW buffer
Hi,
For testing purposes, you probably should use a Linux host. Then you
could use usbmon on the host to see what's happening, and there would
be more debugging options available.
Got it, i will get a PC to install Linux.
Did you enable the two debugging options in file_storage.c? And
Hi,
Replying my email, i set the ep,name to ep1 for bulk out and bulk in
endpoints. The ep_matches() in epautoconf.c is able to auto-configure
the bulk out to endpoint 1.
Are you sure the name string is set to ep1 for both endpoints? (Or
ep1in and ep1out?) If the string was instead set to
1 - 100 of 101 matches
Mail list logo
