>>>> * Who can help write test firmware? >>> >>>I think I could. Something like data source/sink or loopback for EZUSB-FX. >> >>Great! Right now it's expecting to talk to a data source/sink. A useful >>update would be sourcing patterned data, so dropouts can be noticed. Could >>you help get a GPL'd version of that together? > > > Yes, think so. For the FX it's not much more than modifying some > of my existing stuff here. I believe I could easily change this to work > with both 2131 and FX. FX2 would be a different story. I think it > shouldn't be too hard to write it from scratch based on the TRM docs, but > I don't have access to a FX2-SDK for testing.
Thanks to Cypress, I do. Cypress has some code -- 'a3load' at least -- that runs on all three microcontrollers, and if we keep the logic simple we could do the same thing. We'd likely just need a couple non-control endpoints per device, and to the extent that handling an IRQ is just priming a pump, it's not unreasonable to have both FX/an21xx and FX2 versions > Wrt. to sourcing data, IMHO the following would be useful options: > - 32 bit packet counter, current value transmitted in first 4 bytes of > every packet > - payload set to all-0 or all-1 to cover best/worst case bit stuffing It's easy to see what the host would do with an error (report/fail), but it's less clear to me what a device would do if it notices a "skipped" packet, or a byte with the wrong value. Maybe just halt the endpoint. > - always send max packet size (64 byte for FS), continous data stream Eventually we'd want to test all maxpacket sizes, but that sort of stuff can IMO wait for a while. After all, we're running into problems with urb queueing even before we start to look at the data ... :) > - sending occasional short packages (1...63) at random > - sending max size packets, but with a zero packet inserted at some rate Not at random ... at most, according to some pseudo-random sequence known in advance to both host and device. They should know in advance what packet will be coming. We'll need to test short packet I/O ... so something as simple as a data stream option to make the packet sizes go MAX, MAX-1, ... 2, 1, 0 would be enough to test with. (Instead of a default that sends only MAX.) > - sending usb (micro-)frame number as packet payload so the host could > measure latencies > - use another OUT ep so the host could request a sudden functional STALL > on the source ep. I'm not sure what you mean about microframes, those are only for high speed. As for requesting faults (like endpoint halts), I had thought those would be done with control requests. If for no other reason than to conserve the use of endpoints ... the EZ-USB controllers have more than most, and it'd be handy if people can use devices like SA-1100 based PDAs for testing. So we shouldn't design the test protocol to rely on extra endpoints. (Which would add another variable to the mix, given what I'm told about the proclivity of some such microcontrollers to garble data as it goes between the USB glue and the CPU.) >>And loopback is needed too. I'd like to see a loopback that buffers more >>than a single packet, so the read side and write side of "loopback and check >>data" style tests would have the opportunity to get out of sync. > > > My loopback has the IN and OUT ep's both double buffered (2x64 byte, so > the device doesn't need to NAK while the firmware processes the data) and > a 2KB ringbuffer, i.e. the data stream is: > > USB OUT -> flip buffer -> ringbuffer -> flip buffer -> USB IN > > The whole thing is interrupt driven and the transfers between flip buffers > and the ringbuffer is done via DMA. As long as the host keeps the reads > and writes nearly balanced you'll never get a NAK from the device. I've > measured 1.19e6 bytes/sec sustained throughput with usb-ohci and queueing. Well, that sounds exactly like what I want to know works for _all_ host controllers!! But I'd make sure the host unbalances the reads and writes, in some test modes, to make sure interesting behaviors get triggered! > I doubt there could be any useful firmware made working with both FX and > FX2 because _all_ functional registers and endpoint buffers buffers have > changed location. See above. The simpler we keep the test firmware, the easier this is to achieve. Sure the autovector tables need switching, and FX2 needs to be able to toggle between high speed and low speed mode ... but a "fill that buffer" routine can use (auto)pointer + size, leaving not a lot of setup that needs to be chip-specific. (I'd expect so, anyway.) And keeping the behavior simple will make it easier for other devices (not EZ-USB) to be used in testing. > And if you think about running the test firmware downloaded to arbitrary > ezusb-family based devices, there are further concerns even for a > particular device: Most of which we should design to avoid. There's a lot that can be done in just 4KBytes (in a byte-efficient ASM!), and running on every possible hardware would mean revision-specific bug workarounds as well as "how did vendor X use it" issues. Some modes are mainstream, and others we can/should ignore. The reason to try handling lots of devices is to make it easier for people to use this without needing to get hardware-developer kits (such as those at http://csx.jp/~fex/ezusb/buy-en.html) ... easier to just go to the corner store and get a usb serial adapter to re-purpose, but not the only choice. (I did once see an FX2 based kit, but I lost its URL.) - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
