Quantcast

EEPROM handling work

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

EEPROM handling work

Uwe Bonnes
Hello,

appended tar file contains 78 git patches that bring libftdi EEPROM handling
to a state that lets me read and write FT2232C/FT232R and FT2232H on
different boards with different setting with no error found yet when
decoding later with FTDI tools.

Usage pattern is like
 * (open device)
 *  ftdi_eeprom_initdefaults(ftdi, "My_MANU","MY_DESC","MY_Serial")
    with libftdi setting values according to ftdi->type
 * change ftdi->eeprom->xx items according to local needs
 * ftdi_erase_eeprom()
    where the connected EEPROM is checked for type (none, internal on
    FT232R, 93x46, 93x56 or 93x66), as EEPROM chip size influences
    EEPROM layout
 * ftdi_write_eeprom()

As nearly all EEPROM handling needs to know ftdi->type and usage of
ftdi->error_str comes handy, I changed the API to work on struct
ftdi-context. "struct eeprom" and string buffer handling is now done inside
libftdi, so some APIs formerly needed to (intransparently) manipulate these
items are removed.

ftdi_write_eeprom_location() now checks that the requested location is above
the checksum protected area ending at 0x7f and the connected EEPROM is type
93x66, as otherwise the checksum protected area is written without update of
the checksum and the FTDI chip will not use EEPROM content on next
enumeration.

Some User area functions to access free EEPROM space in the checksum
protected area below 0x80, like provided by ftd2xx _UAxx functions, may come
handy but are not yet provided.

In the examples directory the eeprom.c file allows to
* read the EEPROM ("eeprom")
* dump the EEPROM content that would be written ("eeprom -d") as the result of
  calling ftdi_eeprom_initdefaults for the connected FTDI chip
* erase ("eeprom -e")
* write the eeprom ("eeprom -w")
Use at your own risk, as wrong settings may result in FTDI boards no longer
able to enumerate. You need to unsolder the EEPROM and solder a clean chip
in that case.

Command line options allow to specify the value for ftdi_usb_open_desc() to
select a specific device when several FTDI devices are connected to the same
PC.

I propose also to move all EEPROM related code to a seperate file, as ftdi.c
is quite big now

Please let me know comments, issues, improvement and fixes.

Bye
--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

out.tar.gz (55K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

DJ Delorie

> Usage pattern is like
>  * (open device)
>  *  ftdi_eeprom_initdefaults(ftdi, "My_MANU","MY_DESC","MY_Serial")
>     with libftdi setting values according to ftdi->type
>  * change ftdi->eeprom->xx items according to local needs
>  * ftdi_erase_eeprom()

This is wrong for the FT232R.  For that, you always read the existing
eeprom data first, *then* make changes.  Never start with a blank
eeprom or you'll lose the unique serial number that FTDI puts in each
FT232R, which is stored *after* the regular eeprom data!  This number
is separate from the MY_Serial in your email, although FTDI puts a
unique one of those in also, which your use pattern would lose.

Here's a dump from a factory-defaults FT232R chip.  Note the extra
data after 0x80 and the pre-existing usb serial number:

Dev  0: Filename "102", Manf "FTDI", Desc "FT232R USB UART", Ser# "A600dOgq"
00  :  00 40 03 04 01 60 00 06  a0 2d 08 00 00 00 98 0a  :  .@...`.. .-......  :  00
10  :  a2 20 c2 12 23 10 05 00  0a 03 46 00 54 00 44 00  :  ....#... ..F.T.D.  :  10
20  :  49 00 20 03 46 00 54 00  32 00 33 00 32 00 52 00  :  I...F.T. 2.3.2.R.  :  20
30  :  20 00 55 00 53 00 42 00  20 00 55 00 41 00 52 00  :  ..U.S.B. ..U.A.R.  :  30
40  :  54 00 12 03 41 00 36 00  30 00 30 00 64 00 4f 00  :  T...A.6. 0.0.d.O.  :  40
50  :  67 00 71 00 00 00 00 00  00 00 00 00 00 00 00 00  :  g.q..... ........  :  50
60  :  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  :  ........ ........  :  60
70  :  00 00 00 00 00 00 00 00  00 00 00 00 00 00 10 94  :  ........ ........  :  70
80  :  31 04 ce fb 00 00 cb 38  32 60 42 00 00 00 00 00  :  1......8 2`B.....  :  80
90  :  00 00 00 00 00 00 00 00  36 41 5a 53 4c 32 33 45  :  ........ 6AZSL23E  :  90
a0  :  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  :  ........ ........  :  a0
b0  :  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  :  ........ ........  :  b0
c0  :  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  :  ........ ........  :  c0
d0  :  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  :  ........ ........  :  d0
e0  :  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  :  ........ ........  :  e0
f0  :  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  :  ........ ........  :  f0

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

Uwe Bonnes
>>>>> "DJ" == DJ Delorie <[hidden email]> writes:

    >> Usage pattern is like * (open device) *
    >> ftdi_eeprom_initdefaults(ftdi, "My_MANU","MY_DESC","MY_Serial") with
    >> libftdi setting values according to ftdi->type * change
    >> ftdi->eeprom->xx items according to local needs * ftdi_erase_eeprom()

    DJ> This is wrong for the FT232R.  For that, you always read the
    DJ> existing eeprom data first, *then* make changes.  Never start with a
    DJ> blank eeprom or you'll lose the unique serial number that FTDI puts
    DJ> in each FT232R, which is stored *after* the regular eeprom data!
    DJ> This number is separate from the MY_Serial in your email, although
    DJ> FTDI puts a unique one of those in also, which your use pattern
    DJ> would lose.


I forgot to mention:
On FT2232R, the USB control message
   libusb_control_transfer(ftdi->usb_dev, FTDI_DEVICE_OUT_REQTYPE,
    SIO_ERASE_EEPROM_REQUEST, 0, 0, NULL, 0, ftdi->usb_write_timeout) < 0)
doesn't do anything  and the new code returns even before
sending the control message. Only data below 0x80 is considered writable at
all under checksum protection.

Daring now to give my code a try?

Bye

--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

DJ Delorie

> Daring now to give my code a try?

When I get time, sure.  My tool can backup and restore eeproms anyway
(based on my last attempt to do eeprom editing, which didn't go so well :)

Hmmm... I'll try it on my ft2232h board, it has a blank external
eeprom anyway.

But the tool I ended up writing is a tweaker - it always reads the
eeprom *anyway*, lets you tweak the values, then puts it back in:

  $ ./eeprom -cbus2 io
  1 device connected
  Dev  0: Filename "103", Manf "FTDI", Desc "FT232R USB UART", Ser# "A600dOgq"
  writing out new EEProm...

I've not yet had the need to write out a whole new eeprom from
scratch, so why is that the default use model?  I would think we'd
want to encourage people to do a read/modify/write cycle instead, for
chips with built-in eeproms like the 232R.

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

Uwe Bonnes
>>>>> "DJ" == DJ Delorie <[hidden email]> writes:

    >> Daring now to give my code a try?

    DJ> When I get time, sure.  My tool can backup and restore eeproms
    DJ> anyway (based on my last attempt to do eeprom editing, which didn't
    DJ> go so well :)

    DJ> Hmmm... I'll try it on my ft2232h board, it has a blank external
    DJ> eeprom anyway.

    DJ> But the tool I ended up writing is a tweaker - it always reads the
    DJ> eeprom *anyway*, lets you tweak the values, then puts it back in:

    DJ>   $ ./eeprom -cbus2 io 1 device connected Dev 0: Filename "103",
    DJ> Manf "FTDI", Desc "FT232R USB UART", Ser# "A600dOgq" writing out new
    DJ> EEProm...

    DJ> I've not yet had the need to write out a whole new eeprom from
    DJ> scratch, so why is that the default use model?  I would think we'd
    DJ> want to encourage people to do a read/modify/write cycle instead,
    DJ> for chips with built-in eeproms like the 232R.

I hopefully will get back soon a batch of 26 boards with FT2232H and blank
93x66 on it.  So no easy way to tweak in that case.

But the other usage pattern the new code allows is:
* open device
* ftdi_read_eeprom()
* tweak values
* ftdi_erase_eeprom() (NOP) on FT232R
* ftdi_write-eeprom()

Even so my first mail was long, I shoudl have made it longer...

Bye

--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

DJ Delorie

> I hopefully will get back soon a batch of 26 boards with FT2232H and blank
> 93x66 on it.  So no easy way to tweak in that case.

Understood, but I've got a box of 500 boards with FT232R on them to
deal with...  and I need the unique serial numbers.

So we're both biased :-)

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

Uwe Bonnes
>>>>> "DJ" == DJ Delorie <[hidden email]> writes:

    >> I hopefully will get back soon a batch of 26 boards with FT2232H and
    >> blank 93x66 on it.  So no easy way to tweak in that case.

    DJ> Understood, but I've got a box of 500 boards with FT232R on them to
    DJ> deal with...  and I need the unique serial numbers.

With "unique serial number" you mean information located above 0x7f (or
16-bit word 0x3f)? New EEPROM code reads out that area and provides read access
to it via ftdi->eeprom->buf, but doesn't try to write and doesn't allow to
write above Byte 0x8f.

Here output of my "eeprom" example on a FT232R after some write :
# ../examples/eeprom  -p 0x6001
Chip type 3 ftdi_eeprom_size: 128
0x000: 00 40 03 04 01 60 00 06  80 2d 08 00 00 02 98 0a .@...`.. .-......
0x010: a2 16 b8 0a 23 10 05 00  0a 03 49 00 4b 00 44 00 ....#... ..I.K.D.
0x020: 41 00 16 03 4c 00 4c 00  42 00 42 00 43 00 5f 00 A...L.L. B.B.C._.
0x030: 43 00 4f 00 4e 00 4e 00  0a 03 30 00 30 00 30 00 C.O.N.N. ..0.0.0.
0x040: 32 00 02 03 00 00 00 00  00 00 00 00 00 00 00 00 2....... ........
0x050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
0x060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
0x070: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 58 e5 ........ ......X.
0x080: 25 04 da fb 00 00 fd 51  32 80 42 00 00 00 00 00 %......Q 2.B.....
0x090: 00 00 00 00 00 00 00 00  38 41 4a 53 57 47 44 4a ........ 8AJSWGDJ
VID:     0x0403
PID:     0x6001
Release: 0x0600
Bus Powered:  90 mA
Manufacturer: IKDA
Product:      LLBBC_CONN
Serial:       0002
Checksum      : e558
Internal EEPROM
PNP: 1
Channel A has Mode UART VCP
C0 Function: TXLED
C1 Function: RXLED
C2 Function: TXDEN
C3 Function: PWREN
C4 Function: SLEEP


"SERIAL" is the same number as with put visual on the board.

--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

DJ Delorie

> With "unique serial number" you mean information located above 0x7f

Yes.  I think this is the "New USB FTDIChip-ID(TM) feature" they
mention on their web site.

http://www.ftdichip.com/Support/Documents/AppNotes/AN232R-02_FT232RChipID.pdf

> 0x080: 25 04 da fb 00 00 fd 51  32 80 42 00 00 00 00 00 %......Q 2.B.....
> 0x090: 00 00 00 00 00 00 00 00  38 41 4a 53 57 47 44 4a ........ 8AJSWGDJ

The 8AJSWGDJ is the number I use.

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

Thomas Jarosch
In reply to this post by Uwe Bonnes
Hello Uwe,

On Wednesday, 15. September 2010 18:26:30 Uwe Bonnes wrote:
> appended tar file contains 78 git patches that bring libftdi EEPROM
> handling to a state that lets me read and write FT2232C/FT232R and
> FT2232H on different boards with different setting with no error found
> yet when decoding later with FTDI tools.

Wow! Congratulations on that one. According to the commit dates,
this only took you like seven days to decode...

> As nearly all EEPROM handling needs to know ftdi->type and usage of
> ftdi->error_str comes handy, I changed the API to work on struct
> ftdi-context. "struct eeprom" and string buffer handling is now done
> inside libftdi, so some APIs formerly needed to (intransparently)
> manipulate these items are removed.

After a quick code review, this would have been my first question.
Back in 2003, I intentionally kept those two apart as I thought
the eeprom stuff is not needed for daily operation.

Though it won't hurt except for wasted memory and as it
simplifies things, I'm ok with this.

> I propose also to move all EEPROM related code to a seperate file, as
> ftdi.c is quite big now

Good idea. I also thought about merging the separate ftdi_eeprom tool
into libftdi as new EEPROM features usually require a new libftdi
version -and- a new ftdi_eeprom version.

ftdi_eeprom was a standalone program as I didn't want to burden
normal libftdi users to install libConfuse back in the days.

Maybe we could just disable the build of ftdi_eeprom
if libConfuse is not installed?

I'll check your decoded EEPROM map with the sparse NDAed documents I have
floating around for the old chip types. Could take me some days
as I'm still catching up from the holidays.

How should we proceeded? If you don't mind I'll put this into a separate
git branch so we can cook it further without serious EEPROM API breakage
for everyone else ;)

Cheers,
Thomas

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

Uwe Bonnes
>>>>> "Thomas" == Thomas Jarosch <[hidden email]> writes:

    Thomas> Wow! Congratulations on that one. According to the commit
    Thomas> dates, this only took you like seven days to decode...

I played longer with mprog/ftd2xx examples running under Wine and forwarding
Windows ftd2xx calls to Linux ftd2xx calls.

    Thomas> How should we proceeded? If you don't mind I'll put this into a
    Thomas> separate git branch so we can cook it further without serious
    Thomas> EEPROM API breakage for everyone else ;)

I can tar-gz my git tree and send you. Would that be enough that you can "git
pull" from the unpacked tree on your PC to keep the history?

If people give feedback on branches, I am fine with a branch.

Bye
--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

Thomas Jarosch
On Thursday, 16. September 2010 11:38:34 Uwe Bonnes wrote:
> >>>>> "Thomas" == Thomas Jarosch <[hidden email]> writes:
>     Thomas> Wow! Congratulations on that one. According to the commit
>     Thomas> dates, this only took you like seven days to decode...
>
> I played longer with mprog/ftd2xx examples running under Wine and
> forwarding Windows ftd2xx calls to Linux ftd2xx calls.

Guessed so ;)

> I can tar-gz my git tree and send you. Would that be enough that you can
> "git pull" from the unpacked tree on your PC to keep the history?

The "git format-patch" tarball you already sent almost worked,
it failed add the "Correct cast" patch.

It should work like this:
- Run git format-patch to output the corresponding patches against "master".
- Use as fresh checkout from the master branch
  and do a "git am /path/to/patches/*.patch".
  It should apply cleanly.
- Create a tarball of those patches and send them to me.
  I'll then pump them into a "eeprom-new" branch.

> If people give feedback on branches, I am fine with a branch.

Well, I don't want to keep the branch around for a long time. Just want
to make sure we don't break other people's code until we are finished.

Cheers,
Thomas

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

Thomas Jarosch
In reply to this post by Uwe Bonnes
On Thursday, 16. September 2010 11:38:34 Uwe Bonnes wrote:
> If people give feedback on branches, I am fine with a branch.

The new eeprom code is now live in the "eeprom-new" branch.

People can take a look via "git checkout -b eeprom-new origin/eeprom-new"

The code compiles fine, I'll try to verify the output against
the previous code for FT245BM eeproms.

Many thanks to Uwe Bonnes for this work.

Cheers,
Thomas

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

Uwe Bonnes
>>>>> "Thomas" == Thomas Jarosch <[hidden email]> writes:

    Thomas> On Thursday, 16. September 2010 11:38:34 Uwe Bonnes wrote:
    >> If people give feedback on branches, I am fine with a branch.

    Thomas> The new eeprom code is now live in the "eeprom-new" branch.

    Thomas> People can take a look via "git checkout -b eeprom-new
    Thomas> origin/eeprom-new"

    Thomas> The code compiles fine, I'll try to verify the output against
    Thomas> the previous code for FT245BM eeproms.

    Thomas> Many thanks to Uwe Bonnes for this work.

I mde tests with the FT2232C,FT232R and FT2232H, so please double check when
working with AM/BM/FT4232H.

--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: EEPROM handling work

ravjeet
In reply to this post by DJ Delorie
is there any way to edit  serial number on line 0x090
Loading...