Attention is currently required from: Angel Pons, Peter Farley.
1 comment:
Commit Message:
Patch Set #1, Line 9: FT232H-based devices are unable to read over 256 bytes of flash in one
Heh, didn't know Wireshark speaks FTDI/MPSSE :D
I'm also not an expert, but AFAICS the captures look good until the failure
(Frame 90). And there seems to be no error cause reported, only the return
value -ENOENT, which libusb often comments as "cancelled". I'm not familiar
enough with Linux' USB stack to say this for sure, but it seems this is not
a hardware failure.
One more general thought: Is there any other software running that might
try to access the FT232H device? any kernel driver or anything using libusb
should not cause any trouble, but who knows...
Even with the limited error information in the capture, there's something
to see: The first 64K block was read successfully. For the second block,
it received exactly 4*4096B or 32 packets (some of it is FTDI protocol so
it's not aligned to any flash blocks). What would be interesting is if it
always stops at that point or if always on a 4096B boundary. I guess it
would suffice to re-run the capture and check if/how the number of frames
changes. The 4096B these URBs request are probably the default read chunk
size of libftdi. So lowering this (maybe to an odd multiple of 512, e.g.
1536) to see if it still fails after a full chunk might be interesting as
well. If it does it would further increase my suspicion that it's a soft-
ware issue.
Decreasing the read chunk size below 512 (if I have not also decreased the max_data_read) causes a segfault when writing to the output file. (I assume it's trying to read beyond the buffer size, but I haven't looked too deeply into it.)
The final buffer is independent from the read size, hmmm. This sounds more
like a bug causing undefined behavior that is only visible much later. I
wonder why libusb doesn't complain already (for me it did with an overflow
error). It seems unrelated but if you want to investigate this further,
please show the patch for your changes.
To view, visit change 63798. To unsubscribe, or for help writing mail filters, visit settings.