Re: [Openocd-development] Errors encountered programming an FPGA using 13MB SVF file

[Sam J. <sam...@st...>]

On 26/08/11 19:18, Andreas Fritiofson wrote:
>
>
> On Fri, Aug 26, 2011 at 7:10 PM, Sam Jansen <sam...@st... 
> <mailto:sam...@st...>> 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
>
>