Ticket #321 (closed defect: fixed)

Opened 10 years ago

Last modified 9 years ago

ftdi_eeprom often fails silently

Reported by: werner@… Owned by: openmoko-kernel
Priority: high Milestone:
Component: default component Version: Version 2
Severity: critical Keywords:
Cc: laforge@…, buglog@…, tony_tu@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

Trying to change the EEPROM content with ftdi_eeprom (under Linux) often
yields no or only partial results. In all those cases observed so far,
ftdi_eeprom indicated that the operation was *successful*, even though
the result was not as expected.

So far, I (Werner) have the following three cases:

  • prototype series board: USB IDs do not change
  • end-of-March board: USB IDs do not change
  • another end-of-March board: USB IDs change, strings are not set

Apparently, Nils Faerber experienced the same kind of problem. On the
other hand, Harald said that he programmed several boards without such
problems, so this bug may depend on external factors.

The ID change can be verified as follows:

  • program the board
  • unplug USB
  • re-plug USB
  • lsusb -d 0x1457: should print something like this: Bus 002 Device 057: ID 1457:5118

The strings are best observed with usbview, which will show a lot of
question marks where the name of the device and its manufacturer should
be.

I'll gather more data to get a clearer picture of what's going on here.

Change History

comment:1 Changed 10 years ago by werner@…

  • Cc tony_tu@… added

comment:2 Changed 10 years ago by werner@…

More data: according to the data read back from the EEPROM, the board
where the IDs are okay and the board where they aren't, both a) have
indeed the EEPROM content ftdi_eeprom intended to write, and b) the
two EEPROM contents are identical.

A cursory check of the code in libftdi-0.9/src/ftdi.c:ftdi_eeprom_build
vs. the EEPROM content indicates that the EEPROM contains indeed what
was intended there. (E.g., that we don't have any integer size or byte
order issues.)

As a further verification step, I read back the EEPROM of my JTAGkey.
Now it gets spooky: that EEPROM contains only the IDs, but no strings.
However, usbview and lsusb happily print them. A quick search in
/usr/share/misc/usb.ids turned up neither the JTAGkey product ID, nor
any of the JTAGkey-specific strings. So it seems that this information
does indeed come from the USB device.

Also checked schematics and data sheets, for good measure. Everything
looks good there.

Closer inspection reveals that the string descriptors have quite
reasonable sizes, which indeed correspond to what lsusb et al. show.

Hmm. That looks interesting. If my suspicion is right, ftdi_eeprom
didn't get all too much testing with >64 words parts ...

comment:3 Changed 10 years ago by werner@…

Solved the strings problem. Since our EEPROM (a 93C56) is larger than 128
bytes, the address wrapping libftdi-0.9/src/ftdi.c assumes doesn't happen.
So we have to a) put the strings above 0x80 (the descriptors want the
addresses there, says the code, without explaining why), and b) write 256
instead of 128 bytes.

SVN: developers/werner/libftdi-c56-strings-dirty-hack.patch

Note that this doesn't solve the "programming ignored" problem. But I
suspect something along very similar lines there.

I also don't quite understand through which magic Harald got his boards
to work completely. Perhaps there is some sort of fallback mode that
simulates the wrap-around in the FT2232 if we just ask nicely.

comment:4 Changed 10 years ago by werner@…

I hate to say this, but the "can't program" issue seems to be hardware.
While fiddling with power to the "new" board that didn't want to be
programmed (I was setting it up for automated tests involving power
cycling), I all of a sudden got the "official" IDs. Needless to say, if
I just pulled and re-connected the good old USB plug, it reverted to the
default settings.

Now I just wish my scope had a PC output so that I could make my test
rig take pictures when "something happens" ...

Again, this is what happens:

  • program the board with (hacked) ftdi_eeprom: success
  • read back with ftdi_eeprom: EEPROM content is perfect
  • power cycle (unplug, then re-plug USB): board comes up with default values
  • power cycle in a different way (*): board comes up with the correct settings

(*) I haven't reproduced the exact timing yet. Also, since I only cut

VBUS, there may be some sneak current through D+/D-.

So this looks as if a logical level is marginal, the EEPROM doesn't
come up fast enough, or the FT2232 comes up way too quick.

comment:5 Changed 10 years ago by werner@…

I'm now automatically cycling upstream VBUS in order to exercise the
board initialization. Unfortunately, the board now consistently uses the
default settings :-(

During my testing, I observed that VCC5 doesn't look good. There is
a typical cycle if I limit the current drawn from upstream VBUS to about
50-200 mA:

http://people.openmoko.org/~werner/dbgnp.jpg

CH1 is VCC5 (= VBUS from upstream), CH2 is CS of the AT93C56A
(I often also only get the first burst on CH2, and it stays low
during the anomaly, so don't pay too much attention to CH2.)
That spike around -500 ms from the center looks a bit disturbing.
This is what it looks like magnified:

http://people.openmoko.org/~werner/dbgnp-zoom.jpg

I've not been able to correlate this to any signal changing at
exactly the same time. However, LED7 begins its long blink about
7-8 ms before VCC5 collapses, and several other signals change
around that time as well.

If I allow a larger current, VCC5 doesn't break down as much, but
still shows a disturbance. So my suspicion is that something is
briefly causing a short, which then upsets the system.

I think this needs looking at by the hardware group.

comment:6 Changed 10 years ago by stefan@…

  • Status changed from new to assigned

Werner, have you now fully debugged this problem?

comment:7 Changed 10 years ago by werner@…

I'd consider the software side fully analyzed, but I have yet to make
a clean fix for libftdi and ftdi_upstream, and submit it upstream. There
have been no news for the hardware side so far.

comment:8 Changed 10 years ago by willie_chen@…

  • Owner changed from werner@… to willie_chen@…
  • Status changed from assigned to new

comment:9 Changed 9 years ago by roh

  • Owner changed from willie_chen@… to willie_chen

comment:10 Changed 9 years ago by john_lee

  • Owner changed from willie_chen to openmoko-kernel
  • Status changed from new to assigned
  • HasPatchForReview unset

what's the status now?

comment:11 Changed 9 years ago by werner

  • Status changed from assigned to closed
  • Resolution set to fixed

Oh, this was a hardware problem: the capacitative load on upstream VBUS
was way too large, causing VBUS to collapse under the inrush current
just at the moment when the FTDI chip tried to read from the EEPROM.

Fixed with debug board v3.

Note: See TracTickets for help on using tickets.