I'm pretty much confused by the padding, did you try what it replies
without a padded write?

5 comments:

File digilent_spi.c:
- Patch Set #4, Line 221: uint8_t res[read_follows ? 10 : 6];
  Looking at iceBurn, the meaning of the bytes seems known? 2-byte
  status, received write length, returned read length. Why not check
  them?
- Patch Set #4, Line 230: int len = writecnt + readcnt;
  This seems flawed or at least confuses me too much. If I read iceBurn
  correctly, it pads up to `readcnt` so the length of the write is `MAX(
  writecnt, readcnt)` but not `writecnt + readcnt`. The length of the
  read in iceBurn seems to always be `readcnt` without anything to drop
  from the read data.
- Patch Set #4, Line 236: memset(buf + writecnt, 0xff, readcnt);
  iceBurn pads with zeros, aiui. And not by `readcnt` bytes but only
  up to a total length of `readcnt`.
- Patch Set #4, Line 246: ret = libusb_bulk_transfer(handle, DATA_WRITE_EP, buf, len, &tx_len, USB_TIMEOUT);
  Maybe we should check `tx_len` as well.
- Patch Set #4, Line 276:
```
	.max_data_read	= 64,
	.max_data_write	= 64,
```
  These are about the payload size, i.e. data actually read / written
  from / to the flash storage. iceBurn seems to use 64 as a limit for
  the bulk transfers, though, which will include the SPI command
  and address. So to limit the bulk transfer to 64 bytes, we should
  set 59 here, I guess. OTOH, if you'd implement a loop around the
  64 byte bulk transfers like iceBurn, we wouldn't need a limit here
  (could speed things a little up due to less protocol overhead).

To view, visit change 23338. To unsubscribe, or for help writing mail filters, visit settings.