On Fri, Aug 26, 2011 at 7:10 PM, Sam Jansen <[email protected]> wrote:
> ** > Hello, > > In attempting to use openocd with an Amontec JTAG key to program a Xilinx > FPGA, I encountered a series of issues I though others might be interested > in. I don't have sensible proposed solutions for any of the problems I > encountered, but perhaps someone on this mailing list is interested all the > same. > > The SVF file is a few SVF commands, with one very large SDR command in the > middle; something like: > > SDR 27025501 TDI (00000000800000008000 ... ) SMASK (1fffffff ... > > This was generated by some Xilinx tools I believe. The file was roughly > 13MB large, most of which was this one SDR command. > > The first problem is that openocd failed to read the SVF file; with the > error message: > > buffer is not enough, report to author > > Not sure which author this is talking about, so I thought I'd inspect the > code. And so the saga began... > > This code here is within an "#if 1" clause, the "#else" looks like it had > code to dynamically allocate enough memory for the command. Unfortunately, > just changing the "#if 1" to an "#if 0" was not enough - I tried this once I > got things working and ended up with strange TDO check errors. Hence I ended > up just making the static buffer size large enough for my needs (16MB). > > On it's own, this isn't quite enough: the data gets copied into some sort > of "command" object allocated in cmd_queue_alloc(). I patched this code to > handle allocating sizes of > CMD_QUEUE_PAGE_SIZE; without this I got a > segfault in memcpy() as there is an un-checked memcpy() into the memory on > this command. > > At this point, openocd no longer crashes with my SVF file. Unfortunately I > started hitting USB/FTDI errors. > > Using the open source libftdi (version 0.17) driver I get the following: > > Error: ftdi_write_data: usb bulk write failed > Error: couldn't write MPSSE commands to FT2232 > > Digging into this some more, I found the error was -110 (ETIMEDOUT). > > Using instead the libftd2xx binary driver, I got: > > Error: couldn't read enough bytes from FT2232 device (2 < 3) > Error: couldn't read from FT2232 > > Giving up on that and going back to the libftdi driver, I found the > following mailing list thread, which suggested that the buffer size was too > large: > > > http://lists.berlios.de/pipermail/openocd-development/2009-February/004695.html > > Reducing this buffer size to 768 (from 128K!) did not immediately fix the > problem at all. Instead I got: > > openocd: ft2232.c:403: buffer_write: Assertion `(unsigned) > ft2232_buffer_size < (unsigned) 768' failed. > > I dug into the ft2232_large_scan() function and found this line which looks > like it attempts to do 64K writes at a time: > thisrun_bytes = (num_bytes > 65537) ? 65536 : (num_bytes - 1); > > Changing the 64K in that line to instead use 768 made no difference. I > tried 512. This worked; no more assertion. I don't have justification for > why I needed 512 here > The same logic is in ft2232_add_scan so I guess it works in "normal" cases. At this stage I got the libftdi driver giving the same error message as the > libftd2xx driver: trying to read 3 bytes, only got 2 bytes. This seemed like > progress so I moved on to diagnosing this error. > > I guessed it was just an off-by-one error, and found the following lines, > which looked suspicious: > > if (type != SCAN_OUT) > thisrun_read += 1; > > I commented these two lines out, with again no basis other than guess-work. > ft2322_large_scan is broken to the point where I've doubt that it's ever used in practice. I could never get it to run using a CPU target, but with a 27 Mb scan from an SVF file I guess it will. Thanks for the idea, I didn't think of that. From your description it seems your SDR is an inout scan? One problem with ft2232_large_scan is that, as far as I can tell, the data read back is completely discarded. Maybe the SVF code doesn't support TDO verification, because I doubt it would work. Also there's a memory leak, buffer's never getting free'd. > The ftdi driver is a real mess. I've been trying to clean in up the past days but I'm beginning to think a complete rewrite would be better. /Andreas
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
