We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
I have a product flavor that sports a mass storage device. I don't really need it now, but it is connected to an internal RAM file system which could be handy to have (is security codes are provided), so I want to keep it. The problem is that I think that writing large files to the drive can prevent system tasks other than the USB tasks from running, hence triggering a watchdog reset. I was hoping to limit the transfer rate using the 'bInterval' parameter in the endpoint descriptor, but as long as I keep on using bulk transfers that will have no effect. Is there a way to limit the transfer rate except from answering the host with a NACK...?
Another reason I don't like the introduction of artificial delays is that is rather difficult to scale when the system changes its properties - task number, priority, time slice duration, clock rate, interrupt sources and priority etc. I'd rather use a built in feature, such as provided 'bInterval'.
> I will try, as you suggested, to control the transfer rate using delays in the BulkOut.
Maybe my words were too short. If you implement BulkOut delay with a local delay loop, it doesn't solve your problem, though the USB transfer speed will drop down. The BulkOut delays should be caused by other task of higher priority. > I am indeed using the samples provided by Keil for integrating USB into RTX (using round-robin with time slice yielding).
I reviewed this KEIL MSC (Mass Storage Class) example. "LPC2368 / LPC2378 USB Mass Storage Device Example" http://www.keil.com/download/docs/336.asp
In this implementation, MSC process is driven by interrupt on bulk IN/OUT endpoints. In a quick look, I don't find any routine which occupies core execution so long. As you've implemented "RAM disk", sector access to media doesn't take so long time, too.
How do you fit it into round-robin with time slice? Maybe the problem hides in there.
Tsuneo
I did not investigate in detail yet as I saw the problem on Friday at 18:00. However, the USB tasks have a very high priority, as does the USB IRQ. It seems as if not all tasks in the system get executed while these high priority transactions take place. Is there something wrong with switching to interrupt transfers?
> the USB tasks have a very high priority, as does the USB IRQ. It seems as if not all tasks in the system get executed while these high priority transactions take place.
Tune the interrupt priority using VICVectPriority register. Do you have any task in main loop, which should be assigned higher priority than mass storage? > Is there something wrong with switching to interrupt transfers?
Do you mean turn bulk IN/OUT endpoints of MSC into interrupt ones? In most case, it'll work but no guarantee, because MSC spec explicitly defines the endpoints as bulk.
MSC-BOT spec (usbmassbulk_10.pdf) www.usb.org/.../usbmassbulk_10.pdf
4.4 Endpoint Descriptors The device shall support at least three endpoints: Control, Bulk-In and Bulk-Out.
Good for hobby project, but not for production design.
Do you have any task in main loop, which should be assigned higher priority than mass storage?
No. I will try to tune the priority of the USB interrupt. Thanks for the tip about interrupt transfers that do not belong in a mass storage device!
Tsuneo,
I have reduced task and interrupt line priority and that seems to solve the problem. Thanks.
Tamir
Hello Tsuneo,
Can I use interrupt transfers for a CDC device? or, another type transfer other than bulk? that does not seem to work and I'm wondering if I'm forgetting something/violating the USB spec (I did not find any such prohibition, but maybe I did not look good enough!).
Thanks in advance!
I found this:
The CDC/ACM protocol is defined on USB 2.0 standard. It requires two bulk and one interrupt endpoints.
> Can I use interrupt transfers for a CDC device?
The spec says that Data Class Interface equips bulk or isoc endpoints. But actually, interrupt endpoints work for CDC on Windows, because there is (alomost) no difference on the handling of bulk and interrupt for the CDC device driver side. In this way, low-speed device implements CDC, for which the spec allows neither bulk nor isoc.
CDC120.pdf www.usb.org/.../CDC1.2_WMC1.1.zip
3.4.1 Communications Class Interface The Communications Class defines a Communications Class interface consisting of a management element and optionally a notification element. The management element configures and controls the device, and consists of endpoint 0. The notification element transports events to the host, and in most cases, consists of a interrupt endpoint.
3.4.2 Data Class Interface - If the interface contains isochronous endpoints, on these endpoints, the data is considered synchronous. - If the interface contains bulk endpoints, on these endpoints, the data is considered asynchronous.
Thanks Tsuneo !