[bug #38659] AVRFTDI not working anymore since svn1098 and destroys flash-contents

[avrs-admin]

Tom Thu 04 Apr 2013 11:54:58 AM UTC

I tried to get avrdude working with a FT2232D, Atmega M324P and used the default FTDI pin configuration as described in "avrdude.conf".

I first started with an precompilated Windows-Binary (http://download.savannah.gnu.org/releases/avrdude/avrdude-5.11-Patch7610-win32.zip). This version looks like "it's just working". But all tries to save the flash-content in a raw-binary file ends with an empty file. My hope, the latest svn version will fix it.

Now i tried the last svn version 1139 from 12.03.2013 - first compiled with windows (mingw), second time compiled with linux. Both version not working anymore - i just got a Connection timeout and the flash contents was erased.

Started searching the last svn version 'running' with linux and next buggy svn version ends with the result svn1068 working, svn1098 ist not working anymore. To my regret, it's to much changed between this 2 version to find the bug as outsider.

./avrdude -C ./avrdude.conf -c avrftdi -p m324p

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | >100% 0.04s

avrdude: Device signature = 0x1e9508

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

--> looks like it's working

./avrdude -C >./avrdude.conf -c avrftdi -p m324p -U flash:r:test.bin:r

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | >100% 0.04s

avrdude: Device signature = 0x1e9508 avrdude: reading flash memory:

Reading |                                                    | 0% 0.00savrftdi.c:536 avrftdi_transmit() ftdi_write_data(pdata->ftdic, buf, buf_size + 4) != buf_size + 4: Connection timed out (110)         usb bulk write failed avrftdi.c:536 avrftdi_transmit() ftdi_write_data(pdata->ftdic, buf, buf_size + 4) != buf_size + 4: Connection timed out (110)         usb bulk write failed avrftdi.c:536 avrftdi_transmit() ftdi_write_data(pdata->ftdic, buf, buf_size + 4) != buf_size + 4: Connection timed out (110)         usb bulk write failed avrftdi.c:536 avrftdi_transmit() ftdi_write_data(pdata->ftdic, buf, buf_size + 4) != buf_size + 4: Connection timed out (110)         usb bulk write failed Reading | #                                                  | 1% 20.05s^C

--> flash content destroyed!

file #27825: svn1139_not_working.txt file #27824: svn1097_working.txt file #27891: avrdude-r1139_win_static_libusb-7634714a_libftdi-v0.20_libusb-compat-0.1.4.zip

This issue was migrated from https://savannah.nongnu.org/bugs/?38659

[avrs-admin]

Hannes Weisbach Mon 08 Apr 2013 01:32:39 PM UTC

Thanks for reporting this.

. Can you tell which version of libusb and libftdi you were using for both OS'? . Does r1097 work for you? Nothing changed in avrftdi from r1068 to r1097. So the offending commit would be r1098. . Can you run the readout command for both the last working and the first non-working SVN revision with the "-vvvvv" flags added to both commands and send the respective outputs as attachments?

Thank you for your help.

Best regards, Hannes

[avrs-admin]

Tom Tue 09 Apr 2013 10:00:55 AM UTC

Linux: LibUSB 1.0.9 +  LibFTDI 0.20 Windows: LibUSB-Win32 1.2.6 + LibFTDI 0.20

R1097 (with Linux) looks like it's working, but read file is empty.

"-vvvvv" flags added for latest working and latest svn version r1139 (see attachments)

[avrs-admin]

Tom Tue 09 Apr 2013 10:05:02 AM UTC

Additional Info: the read back flash content of both attachments should be empty (0xff)

[avrs-admin]

Hannes Weisbach Tue 09 Apr 2013 04:52:23 PM UTC

Thanks for following up on this, Tom.

For r1097 avrftdi indeed reads 0xff for the entire flash. I don't know why this does not get written to the output file. Maybe the file already existed and avrdude did not overwrite it?

As for r1139, the correct command stream for the FTDI is generated but it cannot be transmitted (as you probably guessed). There are not many reasons why the transfer would fail. One reason is the USB-device get disconnected (and possibly re-enumerated), for example due to a bad cable. I dismissed this possibility because with another version of avrdude the problem does not manifest. Another reason I could imagine is another piece of software which snatches the device away, for example the ftdi_sio serial port device driver module on Linux or the VCP driver on Windows. This does however not explain why it only happens with avrdude r1139. Maybe you can explain your test setup in more detail or retry without the VCP drivers/the ftdi_sio module unloaded?

Best regards, Hannes

[avrs-admin]

Tom Tue 09 Apr 2013 05:52:45 PM UTC

For r1097, the file not exists before, it's created but empty for raw data (size=0) or starts with some expected stuff for hex-files (but the content is missing).

For r1139, there must be something different. I guess - it can't be a hardware or driver problem, if the previous software version can communicate without problems and the new one stops with the same system, libraries and conditions (just switch to other svn-version and call configure/make).

• A re-enumeration should not occur, because that will create a new node in /dev/bus/usb/... with the wrong rights, i don't noticed.
• removing the ftdi_sio module not helps, same problem as before

Last time i started debugging, the application hangs inside write_flush-function (especially the ftdi_write_data-call), previously used ftdi_usb_purge_buffers, but without deeper knowlege - i don't know what's going on.

Another problem is, if the previous application call failed (Ctrl+C) .. the next call hangs at beginning with:

[..]                                    1    OUTPUT      1      0                                    0    OUTPUT      0      0

         Programmer Type : avrftdi          Description     : FT2232D based generic programmer

avrftdi: Setting pin 4 (ADBUS3) as RESET: low (high active) avrftdi: avrdude info: direction: 0x000b, value: 0x0000 avrftdi: FTDI LOG: 80 00 0b 82 00 00

Looks like the initialization of the FTDI not works properly to start from a clean starting line.

Maybe you can create a working windows binary with latest svn version, if it is working with your hardware (just read a empty flash back in file), it should working with my hardware too.

[avrs-admin]

Joerg Wunsch Wed 10 Apr 2013 08:38:33 AM UTC

For r1097 avrftdi indeed reads 0xff for the entire flash. I don't know why this does not get written to the output file.

When reading flash memory, trailing 0xff bytes are omitted from the output file, because they are simply assumed to be unprogrammed flash cells.

Consequently, if you read back the flash contents from a device that has been erased, the resulting hex file only consists of the end record:

:00000001FF

[avrs-admin]

Tom Wed 10 Apr 2013 10:48:41 AM UTC

Assuming 0xFF are unprogrammed flash cells and not write them to files is confusing.

• Maybe for a HEX-File this behaviour should be OK, to save filesize and transmission overhead for empty sectors. Maybe it worth to add a option to enable this behaviour. Otherwise there should always 0xFF written, as to Atmel Studio does.
• But for raw binary, not acceptable. That's not what i expect and especially what i told the tool "read 100 bytes" -> result: "0 bytes read". Very confusing.

[avrs-admin]

Joerg Wunsch Wed 10 Apr 2013 10:58:07 AM UTC

As “programming” 0xff into flash is effectively a no-op, what reason should exist to store these bytes in any file? (Sure, in a binary file, intermediate 0xff bytes cannot be omitted; in a hex or s-record file, even that would be possible, but it's currently only done for trailing bytes.)

For EEPROM, things are different, because the assumption is that EEPROM cells will always be erased on a per-cell base right before programming.  (Not all programmers and programming methods actually [can] do this though.)

But for flash, the only way to revert it to 0xff is to chip erase or page erase it (the latter only being supported by programmers for Xmega devices, or by the SPM instruction).

Please discuss this outside of this bug report if you are unhappy with it.  It's not a bug but has been implemented that way deliberately, so if there are fundamental objections, this should be discussed separately on the mailinglist.

[avrs-admin]

Hannes Weisbach Tue 16 Apr 2013 01:13:28 PM UTC

Hi all,

so I built an avrdude binary for Windows:

• from r1139
• 32 Bit
• statically linked against . libusb @7634714a . libusb-compat-0.1.4 (libusb.org was down) . libftdi @v0.20

Works like a charm under Windows 7 x64.

Tom, I have one last idea: you could ./configure libusb with --enable-debug-log. That will be more verbose and hopefully tell us what is going wrong.

Best regards, Hannes

(file #27891)

[avrs-admin]

Hermann Kraus Fri 26 Apr 2013 01:13:14 AM UTC

Sorry, I didn't see this bug before opening #38831. The patch I added there should solve this problem.

[avrs-admin]

Hannes Weisbach Sat 27 Apr 2013 09:56:01 PM UTC

r1142 contains a bugfix as discussed in bug #38831. Since #38831 contains a preliminary patch and discussion to the solution I am closing this bug. Further discussion should take place under #38831.

[avrs-admin]

Tom Tue 30 Apr 2013 01:05:45 PM UTC

It's working now again (tested with Linux), but the support for the FT2232D is now disabled in code. In "avrftdi.c:747-751" between Svn-Version 1141 and 1142 the #if was removed and the FT2232D chip-type is 1 (TYPE_BM).

This chip is working for me with a pin_limit of 7 and package size of 384. Please re-enable it.