On 26/08/11 19:18, Andreas Fritiofson wrote:
On Fri, Aug 26, 2011 at 7:10 PM, Sam Jansen <sam.jan...@starleaf.com
<mailto:sam.jan...@starleaf.com>> 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.
Yes. I should point out that if I remove the large SDR, or use SVF for
other purposes, it works just fine for me. It is purely the large SDR
command that is breaking things.
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.
Actually, this SDR is out only; purely sending data to program an FPGA
and not expecting anything back.
TDO verification does work for "small" commands at least; I use this to
check the FPGA is programmed correctly in a later command and the
verification appears to work just fine (i.e. I've seen the verify raise
an error when it should).
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.
That may be the best solution...
I've also found that with my patch, if I try and run the SVF file twice,
openocd crashes with a malloc error, so I certainly haven't got the code
running perfectly.
If you do go ahead with such, I'd be happy to test your code if that is
helpful.
Cheers,
Sam
/Andreas
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
