FTDI as ISP - grief on my end, any ideas?

[krupski]

Hi all,

I'm playing around with trying to use an FTDI-232RL to act as an ICSP.

I've looked all over the web, I've looked at the AVRDUDE config file, downloaded the FTDI datasheets, ad-nauseaum and still can't seem to get anywhere.

I even found that the older Arduino boards that have an FTDI chip and the 4 extra header pins is supposed to work as a programmer (and I have a Duemilanove board!). I tried both the Duemilanove board and an FTDI breakout board.

I've figured out the FTDI chip pin number to Bit-Bang I/O bit number to RS-232 pin mapping (for example, bit 0 is chip pin 1 is TXD) and this matches what I found on the web and what's in the AVRDUDE config file.

Anyway, it "sorta" seems to work in that the setup is able to READ the signature off the AVR, but it won't go further. I tried a simple chip erase using this command line:

[b]avrdude -c arduino-ft232r -P usb -p atmega2560 -s -e -v -v

[/b]

and I get this back from AVRDUDE:

```
**avrdude: Version 6.1, compiled on Jan  8 2016 at 10:55:26
        Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
        Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/usr/local/etc/avrdude.conf"
        User configuration file is "/root/.avrduderc"
        User configuration file does not exist or is not a regular file, skipping

Using Port                    : usb
        Using Programmer              : arduino-ft232r
        Overriding Baud Rate          : 115200
ft245r:  spi bitclk 115200 -> ft baudrate 230400
        AVR Part                      : ATmega2560
        Chip Erase delay              : 9000 us
        PAGEL                         : PD7
        BS2                           : PA0
        RESET disposition             : dedicated
        RETRY pulse                   : SCK
        serial program mode           : yes
        parallel program mode         : yes
        Timeout                       : 200
        StabDelay                     : 100
        CmdexeDelay                   : 25
        SyncLoops                     : 32
        ByteDelay                     : 0
        PollIndex                     : 3
        PollValue                     : 0x53
        Memory Detail                 :

Block Poll               Page                       Polled
          Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
          ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
          eeprom        65    10     8    0 no       4096    8      0  9000  9000 0x00 0x00
          flash         65    10   256    0 yes    262144  256   1024  4500  4500 0x00 0x00
          lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
          hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
          efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
          lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
          calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
          signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

Programmer Type : ftdi_syncbb
        Description     : Arduino: FT232R connected to ISP
        Pin assignment  : 0..7 = DBUS0..7
          VCC     =  (not used)
          BUFF    =  (not used)
          RESET   =  7
          SCK     =  5
          MOSI    =  6
          MISO    =  3
          ERR LED =  (not used)
          RDY LED =  (not used)
          PGM LED =  (not used)
          VFY LED =  (not used)

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1E9801
avrdude: safemode: lfuse reads as 0xF7
avrdude: safemode: hfuse reads as 0xDC
avrdude: safemode: efuse reads as 0xFC
avrdude: erasing chip
avrdude: Program enable command not successful. Retrying.
avrdude: Program enable command not successful. Retrying.
avrdude: Program enable command not successful. Retrying.
avrdude: Program enable command not successful. Retrying.
avrdude: Device is not responding to program enable. Check connection.

avrdude done.  Thank you.**
```

Notice the line highlighted in red... it seems like AVRDUDE thinks my chip is a 245r when in fact it's a 232r (those have different pinouts).

It seems like it's trying to work, but it just won't go. I looked at the signal lines with a scope and didn't see what I expected to see. With my Atmel ISPMKII (a real one, not a clone), RESET goes solid low, MOSI and MISO scamper up and down at the bitclock rate and SCK sends out nice, as expected, 8 usec pulses... 8 per byte. But the FTDI chip just seems to spit out random trash on all the lines. There is nothing that looks "right".

So, has anyone ever tried this (and gotten it to work)? I know my FTDI devices are all good... they work in their intended applications. I'm sure that I'm "close" to the solution, but it's starting to give me a headache and I don't want to give up.

Anyone??? HELPPPPPPPPPPP!!! Please!

Thanks!

[dmjlambert]

Your calendar must be off by a few days, it is not April 1st.

[dmjlambert]

I have not tried this yet, but have bookmarked what I considered to be the most promising articles about it:
http://forum.arduino.cc/index.php?topic=216889

FTDI Friend

Something to think about for an advanced techie like you, it may be a good idea to try it on a computer where you haven't done modifications to the IDE, updates to avrdude, and stuff like that. Put an old copy of the IDE (1.0.6 perhaps) on an old computer, and use that. Use an older version of the FTDI driver, from back in the day when Lady Ada wrote that article.

I do think it's interesting that she used an FTDI Friend when she had a Diecimila with those extra FTDI pads right there in the picture. There must have been a technical reason, or just selling FTDI Friends, not sure which.

[john1993]

i did program an avr that way back when i was young and foolish (3-4 years ago) and still used ftdi. it took many tries and lots of false information and was so nasty i have repressed most of the details. in fact the front door here now has a poster of ftdi chip with red circle and diagonal bar.

i recall it needed programming into different mode with normal handshake pins repurposed as gpio. it did not work with normal drivers or avrdude or windows and not all ftdi chips. it will be interesting to see if you succeed and how much effort.

so definitely possible but imo not worth it considering more people are waking up to the ftdi situation and switching to more reliable and user friendly silabs or super cheep ch340.

[tf68]

avrdude63 -c arduino-ft232r -P usb -pm328p -U flash:w:Blink.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.10s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "Blink.hex"
avrdude: writing flash (1068 bytes):

Writing | ################################################## | 100% 0.93s

avrdude: 1068 bytes of flash written
avrdude: verifying flash memory against Blink.hex:
avrdude: load data flash data from input file Blink.hex:
avrdude: input file Blink.hex contains 1068 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.60s

avrdude: verifying ...
avrdude: 1068 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:D9, L:F7)

avrdude done.  Thank you.

Well it works here, as you can see. I seem to recall it is the *ONLY* ftdi ft232r bit bang I can get to work. It is hooked up per the avrdude.conf file. I'm using avrdude 6.3 here. I tested it with 6.1 and it fails the same as your test. Update avrdude.
  miso  = 3;  # CTS X3(1)
  sck   = 5;  # DSR X3(2)
  mosi  = 6;  # DCD X3(3)
  reset = 7;  # RI  X3(4)

[krupski]

dmjlambert:
Your calendar must be off by a few days, it is not April 1st.

I'm not kidding. I am trying to figure out how to make it work. I have no plans to do ICSP programming with the FTDI, given that I have Atmel MKII programmers... I just want to see how / if it works.

I've already used the FTDI bit-bang mode along with an SPI interface VFD display to enable me to send data directly from my computer to the display simply by sending it to standard input. It's then easy to make a small program or even a bash script (batch file) to do things like keep a running display of CPU core temperature, HDD space remaining, % of CPU load, etc.... whatever I want to keep an eye on without needing to log in.

At first I send the data to the display byte by byte (which takes a ton of USB overhead along with it). The display updated like it was connected to a 300 baud analog modem of yesteryear. Then I read the data sheet more and discovered that the FTDI has a 64 byte buffer and can blast out up to 64 bytes in one USB transaction. Also, setting the "baud" rate also changes the data transfer rate.

So, I built up "command packets" in a buffer and blasted them out to the FTDI and now it's so fast that I can actually exceed the timing specs of the display (text gets garbled).

This is all it takes to bit-bang synchronous serial data with an FTDI:

// low level bit banger FTDI->VFD
void displayWrite (uint8_t dat, uint8_t reg)
{
    uint8_t buf[64]; // burst out 50 bit patterns
    uint8_t bits;
    uint8_t cmd = 0b11111000; // serial command byte skeleton
    uint8_t c = (SISO | STB | SCK);
    uint8_t idx;
    uint16_t data;

    reg ? cmd |= RS_BIT : cmd &= ~RS_BIT; // select cmd/data
    data = ((cmd << 8) | dat); // build 16 bit command word
    idx = 0;
    c &= ~STB; // assert strobe (low)
    buf[idx++] = c; // copy to buffer
    bits = 16; // 16 bit command word

    while (bits--) { // write out bits
        c &= ~SCK; // lower sck
        buf[idx++] = c; // copy to buffer
        data &_BV (bits) ? c |= SISO : c &= ~SISO; // write a bit
        buf[idx++] = c; // copy to buffer
        c |= SCK; // raise sck
        buf[idx++] = c; // copy to buffer
    }

    c |= STB; // de-assert strobe (high)
    buf[idx++] = c; // copy to buffer
    ftdi_write_data (&ftdic, buf, idx); // write out buffer (50 bytes)
}

The FTDI is a really neat and versatile chip.

[krupski]

dmjlambert:
I have not tried this yet, but have bookmarked what I considered to be the most promising articles about it:
FT232RL: USB to Serial 232 TTL Adapter –?and ISP? - Programming Questions - Arduino Forum
Programming Blank AVRs | FTDI Friend | Adafruit Learning System

Something to think about for an advanced techie like you, it may be a good idea to try it on a computer where you haven't done modifications to the IDE, updates to avrdude, and stuff like that. Put an old copy of the IDE (1.0.6 perhaps) on an old computer, and use that. Use an older version of the FTDI driver, from back in the day when Lady Ada wrote that article.

I do think it's interesting that she used an FTDI Friend when she had a Diecimila with those extra FTDI pads right there in the picture. There must have been a technical reason, or just selling FTDI Friends, not sure which.

Interesting data. That looks like what I'm trying to do.

As far as having a Diecimila in front of her, it's quite possible that:
(a) She wasn't aware of what those 4 pins can do (I didn't know until today)
(b) She didn't want to lose sales to people who own Diecimila and Duemilanov boards!

[krupski]

john1993:
i did program an avr that way back when i was young and foolish (3-4 years ago) and still used ftdi. it took many tries and lots of false information and was so nasty i have repressed most of the details. in fact the front door here now has a poster of ftdi chip with red circle and diagonal bar.

i recall it needed programming into different mode with normal handshake pins repurposed as gpio. it did not work with normal drivers or avrdude or windows and not all ftdi chips. it will be interesting to see if you succeed and how much effort.

so definitely possible but imo not worth it considering more people are waking up to the ftdi situation and switching to more reliable and user friendly silabs or super cheep ch340.

I dunno... everyone seems to hate FTDI. I think they're great. The fact that it purposely has a bit-bang mode built into it makes the chip, all in all, probably more valuable to a hobbyist than the fact that it's a USB to serial converter.

It's possible that a lot of people are unhappy with the incident where a Windows driver update bricked clone FTDI chips but spared genuine ones. Being a dyed-in-the-wool Linux snob, it did my heart good to see Windoze users suffer some more.

Linux users didn't have the problem (nanna-nanna-foo-foo!)

[krupski]

tf68:

avrdude63 -c arduino-ft232r -P usb -pm328p -U flash:w:Blink.hex:i

I read somewhere (today) that AVRDUDE v6.3 seems to support FTDI bit-bang mode properly (finally).

By the way, since you have v6.3, you obviously compiled it for yourself (I'm not aware of any pre-built binaries out there yet). If so, you may wish to fix the BUG that's in it. I discovered the bug today, fixed it and posted how to fix it. See here: There is a BUG in AVRDUDE 6.3 - Microcontrollers - Arduino Forum

[john1993]

Krupski:
Being a dyed-in-the-wool Linux snob, it did my heart good to see Windoze users suffer some more.

Linux users didn't have the problem (nanna-nanna-foo-foo!)

typical nixie attitude.

although im not sure theres any benefit ive been using 6.3 for some months now. average win-wiz, unlike nixie, very considerate and prefer to make life easy for others instead of as painful as possible. so binaries are usually available upon release.

anyway i dug up an old ftdi (using tongs and other proper biohazard equipment) and gave that command line a shot:

no pthread support. please compile again with pthread installed.

"compile again". lol. yeah right! those guys are such practical jokers. not just april 1st either, all year is watch the noobs spin time for them.

[dmjlambert]

john1993, I like your colorful and cute poster, but honestly I don't understand many of the sentences you type. It is like you are writing in a secret language or something. I can't tell for sure if you are bashing an OS of some sort, and if so, which OS you're bashing. I like and have uses for Windows, OS X, and Linux, and even some Solaris thrown in for good measure. All are great and each has drawbacks I'm sure.

[john1993]

i didnt coin the term nixie for linux enthusiasts but did seem to fit. i did come up with BRONIXIE as a takeoff on "brony". true there are benefits and drawbacks to most os but some more that second. i use windows and some linux but only when forced. as mentioned to paul in that other thread even though ive adopted real mode msdos as my personal savior i dont push it at every turn.

for me linux comes a poor third. open source but still only couple percent of pc users, aka the os they cant GIVE away. lol.

krupskis title of this thread and comment pretty much sums it up.

[dmjlambert]

I think I understood the lol part, I've seen that before.

[krupski]

john1993:
anyway i dug up an old ftdi (using tongs and other proper biohazard equipment) and gave that command line a shot:

ROFLM(censored)O!!

"Biohazard equipment"! Too funny!

[pert]

Krupski:
the FTDI chip just seems to spit out random trash on all the lines. There is nothing that looks "right".

Well I don't know if this is relevant to what you're doing and you may be aware of this already but apparently the timing on the genuine FTDI FT232 chips is actually inferior to the counterfeit ones in bit-bang mode(see FTDIgate 2.0? - Page 18) so might be worth trying a fake one to see if it works for you.

[krupski]

pert:
Well I don't know if this is relevant to what you're doing and you may be aware of this already but apparently the timing on the genuine FTDI FT232 chips is actually inferior to the counterfeit ones in bit-bang mode(see FTDIgate 2.0? - Page 18) so might be worth trying a fake one to see if it works for you.

LOL! What's really funny is that I put code into my program to check if the chip is genuine so that I would know (just for my own information)!

I get those waveforms as well... when I forget to connect the 'scope ground lead...

[dmjlambert]

The fake ones have the same PID/VID as the genuine ones. So I don't think that is how to detect a fake.

[krupski]

john1993:
average win-wiz, unlike nixie, very considerate and prefer to make life easy for others instead of as painful as possible. so binaries are usually available upon release.

Whenever I post or provide executable code that is machine specific, I always include pre-compiled WIN-32 binaries in the package. Not because I'm a nice guy, but because I know a 'Doze user:

• Probably doesn't have a Windows compiler
• Probably wouldn't know what to do if he/she did have one
• Probably doesn't even know what a "compiler" or "assembler" is
• Probably is still looking for the proper icon to click for the last console mode program I uploaded

Seriously... I used Windows for years. The first version of Windows I (forced myself to) used was 3.1 when it was basically just a shell on top of MS-DOS. I made it all the way to Windows 7.

For the longest time (several years) I dual booted between Windows and Linux. I forced myself to learn Linux by occasionally booting into it.

Gradually, I found myself booting into Linux more than Windows, so I flipped the boot order so that Linux was the default and I could boot into Windows "if I needed to".

Finally, it got to the point that I was running Linux 100% of the time and the Windows partition was just wasting space. So, I archived all my Windows stuff on my home media server (a 6 hard drive, 16 TiB, RAID6, Linux server based machine) and re-setup my PC HDD to be all Linux.

Then, one day I actually NEEDED to run a Windows program, so I setup a VirtualBox of Windows 7 and now I'm all set. I can run Windows whenever I need to.

I think I last started the VM a year or so ago.......

(Oh... in case 6 HDD / 16 TiB doesn't make sense, that is six 4 TiB drives, and RAID6 uses two for redundancy - that is the system can survive up to two HDD failures at once. I'm not paranoid, but when you have 16 TiB of room and your kids are filling it as fast as they are spending your money, you NEED redundancy!)

It's especially annoying if I have to use or fix (usually fix) someone else's computer and use the command line...

** **C:\> ls Windows** **

Bad command or filename
(arggggggggg!)

** **C:\> dir Windows** **

(lots of stuff spews by)

** **C:\> ls Windows | more** **

Bad command of filename
(ARG!!!!!!! WHY ME????)

** **C:\> cd Windows** **

(astonishment! it worked!)

** **C:\Windows\> cp shell32.dll ..** **

Bad command or filename
(This is as bad as telephone tech support!!!)

** **C:\Windows\> ...ad-nauseaum.....** **

[krupski]

dmjlambert:
The fake ones have the same PID/VID as the genuine ones. So I don't think that is how to detect a fake.

Oh... well then I wonder how a fake IS detected?

Guess I can get rid of my PID/VID checking code... it's useless.

[dmjlambert]

I believe Future Technology has a proprietary and secret method in their closed source Windows drivers. If they revealed how fake chips are detected, the fake chip manufacturers would simply update their fakes to pass the test. They probably test for some subtle and undocumented feature in their own chips that hasn't been implemented in a fake chip. So, the easiest way to detect a fake is to attempt to use it with the latest Windows drivers and see if the "NON GENUINE DEVICE FOUND!" message shows up in the serial stream when you're using it, for example in a loop back test.