On Tue, 1 Oct 2002, David Brownell wrote: > > What about triggering the error paths, i.e. some firmware which produces > > typical device failure modes (like responding too slowly or issues with > > descriptor passing)? > > Absolutely. The most that can be tested with dumb firmware that > sinks/sources packets is software-induced errors, which means just > canceling requests (by unlinking them). Endpoint halts certainly > deserve specific test cases (and clearing of halts).
particularly getting the toggles right there ;-) > It'd be good to have firmware that'd create more than just "typical" > (for who?) failure modes, in fact. Request error N in 17 packets... Sure. The best thing would be some testsuite which allows to validate the drivers (and HC's) against the USB spec, both success and error handling and toleration. But this would be a huge project to do. > >> * 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. 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 - always send max packet size (64 byte for FS), continous data stream - sending occasional short packages (1...63) at random - sending max size packets, but with a zero packet inserted at some rate - 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. > 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. > > Note I have such stuff partly ready here for my testing - need some > > cleanup and checks, but I believe I could provide this rather soon. It > > makes use of special FX-features so it won't run neither on FX2 nor old > > EZUSB (AN2131) devices. > > Hmm, it'd be better to be less specialized. I have a random set of 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. But it's not only rebuilding with another include file representing different register mappings - there are also a lot of semantical changes involved there. Ideas and code fragments can be transfered, yes - but definetedly not whole firmware, neither image nor source with modified include :-( 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: - which clock timing: 12 (FX2), 24 (2131, FX, FX2) or 48 (FX, FX2) MHz - do we have 4 or 8KB internal memory? - is there some memory mapped periphery (like additional memory or whatever) attached to the A/D bus which requires particular bus timing - details about device specific disconnect: it's driven by a programmable I/O pin - but the attached electronics might be active-L or active-H - do we have to - or must not - enable the clockout pin for the device? - Are there components attached to I/O or peripheral busses which expect some non-default setup like pins not floating for longer period or tristated outputs... - do we have the additional 2KB data memory from reclaimable ISO buf (some 2131 and FX flavours have it, not all)? > EZ-USB devices, but they're all either FX2 or AN2131. What FX-only > features? I didn't notice many differences apart from eeprom load, > but then I'd probably have missed them. Sure, it depends on the application, but there are some pretty important functional differences - and even common functionality is implemented differently. In this particular case it is the internal DMA engine. It provides burst data transfers (up to 256 byte) running at 48MB/sec! Without DMA the fastest thing you can do with the 8051 (when running at 48MHz internal clock and 0-waitstates) needs 0.75 usec to copy a single byte in a loop - plus some more time to setup the loop, rearm ep's, interrupt latency... This is just sufficient to saturate the full speed link. If you make a buffered loopback you need to copy the data twice and the 8051 becomes a bottleneck wrt. sustained throughput. With the DMA (including the overhead) I can easily do internal data transfers at 10MB/sec sustained. So you can always saturate the bus at full speed. Unfortunately the DMA engine is only present in the FX! Furthermore, the FX2 (unlike the ISO-capable flavours of 2131 or FX) doesn't have an additional internal 2KB buffer for ISO transfer which can be reclaimed as normal data memory - this is just what I'm using for the buffered loopback. OTOH the FX2 has auto-increment pointers which should be able to take only 0.25 usec for a single byte copy inside a loop. So I'd expect a FX2 loopback might get close to 4 MB/sec IN+OUT load. Anything faster would need some wired hardware around the guy. Conclusion: Firmware can not be shared for FX and FX2. Without making use of some pretty helpful FX features like DMA, firmware could be shared for 2131 and FX. For fullspeed, FX is considerably better than FX2. Highspeed is FX2-only of course. > > I've never tried sdcc - but I do use the generic asxxxx (i.e. as8051) for > > most FX firmware work. sdcc comes with a modified version of asxxxx so it > > Which one must unfortunately use, since 'sdcc' emits such crappy code > for things like const/static arrays. (Wastes lots of memory doing a > runtime init, so you have to use assembler for device descriptors as > well as the interrupt vectors. There's only 8KB, after all!) Right. That was one important reason why I've forgot about using sdcc pretty fast and switched to generic as8051. I had to press some dedicated multi-tasking kernel into the 8KB and there are programmed I/O with less than 100 ns RT requirements, hence it had to be assembler anyway. > > should just work as well. Note the linker creates intel hex format with 32 > > bytes per record. So whatever you use for firmware download, it should be > > prepared to deal with this. > > I thought the version I had generated just 16 bytes? > Maybe I didn't get that far. Easy to tweak 'fxload' > to handle that, if needed. Maybe sdcc comes with a modified version. My ASlink from ASxxxx-3.0 package always issues 32 byte records. Easy to adapt tools, right. Martin ------------------------------------------------------- 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
