bugAVR Downloader/UploaDEr - Bugs: bug #38659, AVRFTDI not working anymore since...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitter:  Tom <hrbn2>
Submitted:  Thu 04 Apr 2013 11:54:58 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  hweisbach Originator Name:  Tom
Open/Closed:  Closed Release:  None
Programmer hardware:  Device type: 

Jump to the original submission

Tue 30 Apr 2013 01:05:45 PM UTC, comment #12: 

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.

Tom <hrbn2>
Sat 27 Apr 2013 09:56:01 PM UTC, comment #11: 

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.

Hannes Weisbach <hweisbach>
Group Member
Fri 26 Apr 2013 01:13:14 AM UTC, comment #10: 

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

Hermann Kraus <herm>
Tue 16 Apr 2013 01:13:28 PM UTC, comment #9: 

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)

Hannes Weisbach <hweisbach>
Group Member
Wed 10 Apr 2013 10:58:07 AM UTC, comment #8: 

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.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 10 Apr 2013 10:48:41 AM UTC, comment #7: 

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.



Tom <hrbn2>
Wed 10 Apr 2013 08:38:33 AM UTC, comment #6: 


> 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


Joerg Wunsch <joerg_wunsch>
Group administrator
Tue 09 Apr 2013 05:52:45 PM UTC, comment #5: 

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.

Tom <hrbn2>
Tue 09 Apr 2013 04:52:23 PM UTC, comment #4: 

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

Hannes Weisbach <hweisbach>
Group Member
Tue 09 Apr 2013 10:05:02 AM UTC, comment #3: 

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

Tom <hrbn2>
Tue 09 Apr 2013 10:00:55 AM UTC, comment #2: 

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)

Tom <hrbn2>
Mon 08 Apr 2013 01:32:39 PM UTC, comment #1: 

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

Hannes Weisbach <hweisbach>
Group Member
Thu 04 Apr 2013 11:54:58 AM UTC, original submission:  

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!

Tom <hrbn2>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by herm (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by hrbn2 (Posted a comment)
  • -email is unavailable- added by hweisbach (Posted a comment)
  • -email is unavailable- added by hrbn2
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-04-27 hweisbach StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2013-04-27 hweisbach StatusNeed Info In Progress
    2013-04-16 hweisbach Attached File- Added avrdude-r1139_win_static_libusb-7634714a_libftdi-v0.20_libusb-compat-0.1.4.zip, #27891
    2013-04-09 hrbn2 Attached File- Added svn1097_working.txt, #27824
        Attached File- Added svn1139_not_working.txt, #27825
    2013-04-08 hweisbach StatusNone Need Info
        Assigned toNone hweisbach
    2013-04-04 hrbn2 Carbon-CopyRemoved hrbn2 -
    2013-04-04 hrbn2 Carbon-CopyRemoved 91006 -
    2013-04-04 hrbn2 Carbon-Copy- Added -email is unavailable-
    2013-04-04 hrbn2 Carbon-Copy- Added hrbn2

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code