avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] [bug #38831] [PATCH] Fix avrftdi onchip-buffer overrun


From: Hannes Weisbach
Subject: Re: [avrdude-dev] [bug #38831] [PATCH] Fix avrftdi onchip-buffer overrun
Date: Sat, 27 Apr 2013 19:21:39 +0200

Am 26.04.2013 um 18:21 schrieb Hermann Kraus:

I digged out my FT2232C and could finally confirm this issue (FT4232H does not 
exhibit any problems).
> On Fri, 26 Apr 2013 13:09:11 +0200, Hannes Weisbach <address@hidden> wrote:
>> this is not an issue, because the FIFO is only of importance in UART mode. 
>> avrftdi uses the MPSSE mode, in which packet sizes are handled by the USB 
>> spec and subsystem of the operating system, specifically libusb.
> 
> I have seen the same problem as in #38659 while trying to verify or read an 
> atmega16.
> I got the same
>> avrftdi.c:536 avrftdi_transmit() ftdi_write_data(pdata->ftdic, buf, buf_size 
>> + 4) != buf_size + 4: Connection timed out (110)
> error messages. Reading an mega8 worked however. I tracked it down to the 
> different "buf_size" values (512 vs. 256). It stops working as soon as 
> buf_size is bigger than 380. Together with the 4 bytes protocol overhead I 
> get exactly the fifo size of 384 bytes.
I see your point, but I am not entirely sure what the chip does. Sending 388 
bytes should be totally fine, since the first three bytes (MPSSE command) do 
not cause any bytes to be placed in the RX buffer, nor does the SEND_IMMEDIATE 
command. I have send an email to FTDI support, may be they will shed some light.
> 
> Everything you write about not caring about packet sizes you wrote is 
> correct. But libusb only handles splitting the data into packets that match 
> the USB endpoint size, but it know nothing about buffers internal to the chip.
You are right. I assumed libftdi did some magic, which it does not do.
> I'm not sure if write-only access would work (I guess it works, as 
> programming the flash does work), but writing + reading data back definitely 
> doesn't work.
I agree.
> 
> Solution c) looked like the easiest one to implement so I chose it.
I have looked a bit around and other projects seem to have similar problems:
. urjtag says, that libftdi can handle only 4 * 64 bytes result data. Maybe 
this info is outdated? 
(http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Cable_FT2232#Performance_Gain)
. libmpsse fixes it's transfer size to 512 bytes, which incidentally is the 
wMaxPacketSize for H-series chips. (https://code.google.com/p/libmpsse/)

In the mean time I have implemented a work-around based on your patch (I have 
not applied your patch because it violated indendation and used a fixed size of 
384). I will do a bit more testing and submit it to SVN this weekend. Thank you 
for pointing me in the right direction on this.

Best regards,
Hannes


reply via email to

[Prev in Thread] Current Thread [Next in Thread]