On Tue, 12 10:06 , Tim Roberts wrote:
>
> > wValue (LSW) and wIndex (MSW) make up the address offset to write
> > the data to within device memory.
>
> Are you sure you have the ordering correct? (It probably is, because
> that lets those two fields be treated as a single little-endian dword.)
>
I'm pretty sure, several posts in the manufacturers forum
mention it. Apart from that, I've tried it the other way round
too. It fails at the first write, as expected.
> > In both cases (r/w), the maximum value for wValue is 0x4000, after
> > that libusb_control_transfer() returns pipe errors. As it is
> > possible with the original tool to write beyond this address, I
> > suspect it's not the device that produces the stall.
>
> What is the actual error code you get from WinUSB? If the error really
> is a stall, then has to come from the device. What is the
> bmRequestType? Is it a vendor request to the device? Would you mind
> showing us the code?
>
I don't see any debug messages (though I enabled the libusbx debug
facility in my code, level 3). I might do something wrong here.
I inferred the fact that it is actually a stall from peeking into
sync.c, which returns a LIBUSB_ERROR_PIPE when transfer->status in
libusb_control_transfer() is LIBUSB_TRANSFER_STALL.
Would I see the WinUSB error code in the libusbx debug log?
The code in question is called each 1024 bytes that are read
from the firmware image file. I've checked the buffer is
actually present and the error also occurs with bogus images:
int CypressFX3Device::WriteRAM(size_t addr,
const unsigned char *data, size_t nbytes)
{
if (!IsOpen())
{
fprintf(stderr, "WriteRAM: Not connected!\n");
return(1);
}
int n_errors = 0;
const size_t chunk_size = 64;
const unsigned char *d = data;
const unsigned char *dend = data + nbytes;
while (d < dend)
{
size_t bs = dend - d;
if (bs > chunk_size)
bs=chunk_size;
uint32_t dl_addr = addr + (d - data);
int r = libusb_control_transfer(
usbhdl, // handle
0x40, // bmRequestType: Host to Device, Vendor, Device
0xA0, // bRequest: Vendor
dl_addr & 0xFFFF, // wValue (LSW)
dl_addr >> 16, // wIndex (MSW)
(unsigned char*)d, // data
bs, // wLength
1000); // timeout in ms
if (r < 0)
{
fprintf(stderr, "Writing %u bytes at 0x%x: %s\n",
bs, dl_addr, libusb_error_name(r));
++n_errors;
}
d += bs;
}
return(n_errors);
}
> > As I don't have any known-good device where I could meaningfully
> > test a control transfer with wValue > 0x4000, I'd also be happy
> > for any hint towards how to reproduce this behaviour.
>
> I have certainly done vendor device requests with wValue larger than 0x4000.
>
You mean with libusb and WinUSB as the driver?
Regards,
/Markus
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
