1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

FT245BM problem: missing/corrupt data

Discussion in 'Embedded' started by abduln, Oct 21, 2005.

  1. abduln

    abduln Guest

    Hello,

    We are facing a corrupt/missing data problem with FT245BM:

    If the "pull down on USB suspend" option is enabled in EEPROM, on
    startup, we get 126 bytes of garbage followed by the first byte from
    host. Subsequent bytes come across fine.

    If the "pull down on USB suspend" option is NOT enabled in EEPROM, the
    first byte from host is never received. Subsequent bytes come across
    fine.

    The algorithm we are using to read is the following:

    1. Wait for RXF to go low
    2. Set RD low
    3. Wait for 200ns
    4. Read data
    5. Set RD high


    - FT245BM connected to ATmega16
    - Configured as bus powered device (100mA)
    - VCC for the ATmega64 is switched using MICREL 2025-2BM power switch.
    Same as Fig 11 (Page 21) on the datasheet but with power switch IC
    instead of MOSFET.

    Any workarounds, debugging tips?

    Thanks,
    Abdul
     
    abduln, Oct 21, 2005
    #1
    1. Advertisements

  2. Have you asked the technical support of FTDI? Their support is very good.

    Meindert
     
    Meindert Sprang, Oct 21, 2005
    #2
    1. Advertisements

  3. abduln

    abduln Guest

    Yes, we did. But they are gone for the weekend. And we have a tight
    deadline :<
     
    abduln, Oct 21, 2005
    #3
  4. abduln

    tusunov Guest

    How long is your USB cable?
    Do you have capacitors at the USB connector?
    Is your FT245 TST pin connected to GND?

    Best regards
    Tsvetan
     
    tusunov, Oct 22, 2005
    #4
  5. abduln

    Kryten Guest

    I've had problems with resetting or turning off my project with
    HyperTerminal running to the USB module. HyperTerminal locks up, no comms,
    and refuses to shut down. My laptop is unable to shut it down from the
    control panel, and the laptop itself is unable to fully shut down - I have
    to pull the power plug and the battery.

    I reckon their FT245BM chip and software needs more work to become robust...
     
    Kryten, Oct 22, 2005
    #5
  6. Really? When evaluating USB/232 chips, I just showed them, how I can
    lock up their FT232-VCP-driver. Easily. Each time I try. Gave them
    some Portmon-logfiles. Offered to give them a sample program.

    Guess, what happens? They told me to try their newest (beta-)driver.

    Same procedure again. Guess, what happens? They thanked for the
    problem report.

    This was about 1,5 years ago. Their driver, which isn't beta anymore,
    still locks up.

    If you call this "very good support", it's one, I can easily live
    without.

    I ended with a silabs chip. No hazzles, responsive and honest support.

    Andreas
     
    Andreas Hadler, Oct 22, 2005
    #6
  7. With a FT232, I experienced lock-ups also. I was able to continue
    working by
    1) disconnect the USB device.
    2) wait some seconds, about half a minute, IIRC.
    3) shut down the locked application with the task manager.

    Still annoying, but no show stopper.

    If I tried to shut down the application before disconnecting and
    waiting, I ended with the same problem as you. Unrecoverable lock-up.

    Andreas
     
    Andreas Hadler, Oct 22, 2005
    #7
  8. abduln

    Ron Belknap Guest

    We were having tons of disconnects and driver lockups with the FT245BM and
    FT232BM chips when connected to USB 2.0.

    We adding 47pF caps to ground on USBDP/USBDM, and a 470nF cap connecting USB
    shield to ground. Testing in our office this eliminated 100% of our
    problems. In the field it eliminated 90% of the problems, as our products
    are used in an environment prone to static. We then went up to 100pF caps
    on USBDP/USBDM, this eliminated 99% of our problems.

    The FTDI documentation, at the time we were doing our design, didn't clearly
    mention the need for these caps. Only the most recent commercial products
    using the FT232/245 have any of these caps, and most still don't have the
    470nF cap connecting USB shield to ground.

    When we initially contacted FTDI support they acted like we probably had a
    flaw in our hardware design. I pointed out that we were using the DLP245PB
    module which would fail even without the rest of our design attached. I was
    also able to reproduce the error on a US232B/LC the evaluation USB-to-Serial
    converter that they sell. Then they recommended that we add the caps
    mentioned above. Neither the US232B/LC or the DLP245PB module, have the
    caps.

    Regards,
    Ron Belknap

     
    Ron Belknap, Oct 22, 2005
    #8
  9. Well, I never really had problems with the chips and drivers. Only once when
    a laptop locked up when going into sleep while a virtual serial port was
    opened. A new driver solved it. But I had a few questions about odd
    baudrates aswered very quickly. Also they helped me well when I wanted a
    special version of the OS X driver with special baudrate behaviour on
    certain PID and all that. No problem, all could be done and was done in no
    time.
    So in that, my experience with FDTI is good.
    Mmmm.... I thought about changing to that one too.

    Meindert
     
    Meindert Sprang, Oct 22, 2005
    #9
  10. abduln

    abduln Guest

    Cable is about 3 feet long.
    No capacitors on the USB connector
    TST pin is connected to ground
     
    abduln, Oct 22, 2005
    #10
  11. We adding 47pF caps to ground on USBDP/USBDM, and a 470nF cap connecting
    USB
    Where exactly did you add the caps on USBDP/USBDM?

    Between the IC and the resistor or between the resistor and the USB
    connector?

    Bertolt
     
    Bertolt Mildner, Oct 22, 2005
    #11
  12. abduln

    Ron Belknap Guest

    Between the resistor and the USB connector.


     
    Ron Belknap, Oct 22, 2005
    #12
  13. abduln

    Kryten Guest

    [snip FTDI not admitting or fixing hardware]

    Thanks for the tip off.

    I hate it when tech support people fob us off with the usual excuses.

    I recall a stepper/servo motor controller chip feature refusing to work, and
    their techies taking weeks to get round to talking to their software guys
    before they confessed they'd run out of ROM and not implemented it. Nobody
    had do

    I politely but firmly read them the riot act...

    Anyway, on my to do list: add capacitor work-arounds, and look for more
    robust chips.

    Anybody know any products similar to FTDI USB modules, but without the
    problems?

    TIA, K.
     
    Kryten, Oct 23, 2005
    #13
  14. You've seen Meindert and me mentioning silabs (the artist formerly
    known as cygnal :)? Their USB/232 worked for me.

    Andreas
     
    Andreas Hadler, Oct 23, 2005
    #14
  15. abduln

    Kryten Guest

    That's a serial port interface, and I don't have a serial port.
    Seems a pointless bottleneck in my application.

    The module I use is a FIFO interface: just hurl bytes at it and use a pair
    of handshake lines, very fast.

    K.
     
    Kryten, Oct 23, 2005
    #15
  16. abduln

    abduln Guest

    Here is the response from FTDI:

    The data corruption/missing data will occur because at power up, the
    device connected to FIFO could toggle the RD/WR lines, this causes the
    internal buffer pointers to advance or load garbage data. To
    synchronise the FIFO do something like the following:

    1) Send a character repeatedly to the FIFO (say 'A').
    2) The device connected to the FIFO should echo this character
    back to the FIFO
    3) When the FIFO starts receiving 'A's it then sends an
    'AB'
    4) Again the external device should then echo back the 'AB'
    5) When the FIFO receives the 'AB' your external device is
    synchronised with the FIFO.

    The synchronisation of the FIFO is particularly needed if the external
    device powers up after the FT245 device.

    If you can power up the micro before the FT245 or exactly at the same
    time you may be able to avoid the problem. Essentially you need to
    ensure the RX/WR pins are not toggled when you are not attempting to
    read or write data.
     
    abduln, Oct 24, 2005
    #16
  17. abduln

    jyaron Guest

    The FTDI system is extremely sensitive and injecting a simple 4vpp 500ns
    transient onto a USB line causes their system to de-enumerate.

    Total cable disconnection and reconnection/re-enumeration is req'd to
    re-establish.

    Their gargabe is not robust at all. I lost thousands of dollars and months
    fixing their sh**.

    I have a galvanic/opto isolation design which is working so far on problem
    hubs (typ. in Dell and Compaq garbage computers) with 5 meter cables in an
    industrial environment.

    I am willing to give anyone interested this design which took me months of
    stress and experimentation to design.
     
    jyaron, Oct 26, 2005
    #17
  18. abduln

    Rocky Guest

    I am interested...
    Regards
    Rocky
     
    Rocky, Oct 26, 2005
    #18
  19. Strange, i can't remember any problems with PWREN#. If i remember correctly
    i had no pullup on PWREN#.

    What i had where multiple edgs on RD/WR while (RESET# == high) and (PWREN#
    == high). These where NOT caused by the uC but definitely by the FT245. I
    could also see them on the scope with RD/WR floationg and even with
    pull-ups to VCC_USB on RD/WR.

    If my memory serves me right part of the problem is that RD/WR are
    pulled-up (by the FT245) before they are pulled-down because the "pull-down
    option" is set in the EEPROM.

    You can see it here: http://www.openprog.org/files/oszi/PWREN_RD_1.jpg


    From my point of view there are multiple design flaws in the FT245:

    - IOs should not be pulled-up until the EEPROM is read and the "pull-down
    option" is evaluated.

    - IMHO it does not make any sense to power PWREN# from VCC_IO. It would be
    much better if VCC_IO could be switched with PWREN#.

    - the FIFO should be reset on (or shortly after) the falling edge on
    PWREN#.

    Bertolt
     
    Bertolt Mildner, Oct 26, 2005
    #19
  20. abduln

    John Strupat Guest

    I'm interested in your design.
    Please email me.

    Regards,

    John Strupat


    ..com...
     
    John Strupat, Oct 26, 2005
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.