Hi Matthias, You wrote on Mon, Sep 30, 2019 at 08:45:24AM +0200: > The way I went with was changing line 570 of ftdi_eeprom/main.c from > if (command == COMMAND_ERASE) > to > if ((command == COMMAND_ERASE) || (command == COMMAND_FLASH)) > > After all, (re-)flashing the chip requires deleting any existing data, so > this did the trick for me. > I am not sure if there are any edge cases where erasing the whole chip is > undesirable.
some chips support storing user data in a reserved area. It has been ages since I last tweaked around the eeproms, but it could be that this area gets cleared by the ERASE command, too. May be someone else can chime in here. > As a side note: It would be nice to have chip size refactored in > src/ftdi.c so the size of the various chips isn't hardcoded in more than > one spot. > (I suggest a function that takes chip type id as parameter and returns > size or values <0 in case of error.) support for different chips and eeprom sizes was growing over the years. The problem here is verifying code changes as I just have a few different devices lying around. The eeprom size also affects the location device strings offsets. See also the "size guessing" code in ftdi_read_eeprom(): commit 2d543486ed96287e3d0f8f33d82321dfc2f835d0 Author: Uwe Bonnes <[email protected]> AuthorDate: Wed Sep 8 15:50:06 2010 +0200 Remove ftdi_read_eeprom_getsize() function. Integrate in into the ftdi_read_eeprom() function. On ftdi_eeprom_write() another approach is needed Cheers, Thomas -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
