Currently I finished project based on TAS1020B.
For first time programming firmware I use DFUTEST.exe from FDK package.
But I would like to write my own PC side application for upgrading firmware (DFUTEST is inappropriate for enduser).
Is available any documentation about using DFUUSB.SYS driver or source code od DFUTEST.EXE?
Best regards,Jaroslaw CzulaPoland
Jaroslaw - the engineer best equipped to answer your question is currently out of the office, returning Mon May 23. I expect you can get an answer shortly after his return. Regards, Lester
> Is available any documentation about using DFUUSB.SYS driver or source code of DFUTEST.EXE?
No, not that I've found.
At this point, it may be better to use WinUSB to develop a DFU capability - but I admit that I haven't tried this just yet (though it is on my calendar).
I've used WinUsb and a custom application to download to a blank EEPROM connected to the TAS1020B. Unfortunately, I don't believe that there's any way to force a bus reset via WinUsb, so this technique doesn't work to download to the TAS1020B RAM (actually, it downloads to the RAM just fine - but you can't get the TAS1020B to start executing from the RAM). If you're interested, please respond, and I'll provide the source, executable, and instructions.
Yes, I am still interested.
I'll be very grateful.
Here's a zip with the files you'll need: 4061.WinUSBTAS1020BDFU.zip
Driver installation:- build your own driver installation package to get WinUSB installed on your PC (or unzip this: 7823.driverInstallPackage.zip) - obtain the latest Windows Driver Development Kit (WinDDK) from Microsoft (7600.16385.0) - build a 'driver install package' (a directory structure on your hard drive works, but you could burn CD with the same directory structure): - dfu.inf [provided in WinUSBTAS1020BDFU.zip] - duf.cat [build this file by running makecat.bat from the zip] - amd64 (directory) - WdfCoInstaller01009.dll (from WinDDK\redist\winusb\amd64 directory) - winusbcoinstaller2.dll (from WinDDK\redist\winusb\amd64 directory) - ia64 (directory) - WdfCoInstaller01009.dll (from WinDDK\redist\winusb\ia64 directory) - winusbcoinstaller2.dll (from WinDDK\redist\winusb\ia64 directory) - x86 (directory) - WdfCoInstaller01009.dll (from WinDDK\redist\winusb\x86 directory) - winusbcoinstaller2.dll (from WinDDK\redist\winusb\x86 directory) - note: dfu.inf and dfu.cat are located in some directory, under which subdirectories 'amd64', 'ia64', and 'x86' have been created, and which hold the two files for the associated architecture from the WinDDK)- attach a TAS1020B having no EEPROM, or blank EEPROM, to your PC- when Windows lets you specify the driver's source location, point it to your directory structure To program a blank EEPROM:- make sure the image file has 'EEPROM overwrite' enabled- unzip 'download.exe' from the zip file- run command 'download <name of image file>'- note that this should program the EEPROM, but will not cause the downloaded image to start running- power-cycle or reboot the TAS1020B
Notes on 'download.exe':- the image file you download must have the header information already prepended- information from the header and TAS1020B is displayed as the download proceeds- download.exe can (and will, if there's no blank EEPROM) write to TAS1020B RAM, but since WinUSB does not provide a mechanism for issuing a bus reset, the TAS1020B will not execute that program.- 'download.exe' doesn't do error recovery - so you may have to reboot the TAS1020B if the download fails- source for download.exe is provided in the zip. I built using VS2010 - here's the project file I used (zipped): 6811.download.vcxproj.zip
Since you are 'Beta Test', please provide feedback!
The download program using WinUSB API's was very helpful. I ported it to C# and created an application for reading/writing our I2S codec registers and programming the EEPROM in DFU mode via the TAS1020B.
Is it possible to overwrite a valid EEPROM image when the TAS is not in DFU mode?
I've tried writing directly to the EEPROM address (0xA0) by way of WinUsb_ControlTransfer. I tried just writing 0's to the EEPROM address to invalidate the header information. That didn't work.
I also modified some application code in the usbmodevm105.bin image to try and write the EEPROM like this function does:
bit dfuWriteEeprom(word Offset, byte *pSource, byte bBytesWritten, byte i2cFlags) which is located in the ROM code file UsbDfu.c. That didn't work either.
> Is it possible to overwrite a valid EEPROM image when the TAS is not in DFU mode?
Two thoughts on this:
- some I2C EEPROMs have a WP pin that can protect the image
- when the TAS is not in DFU mode, it does what the Application program tells it to do. The application would have been read-in during boot time, so it should be able to use I2C to overwrite the EEPROM. When you use WinUsb_ControlTransfer, I'm guessing that your application installed a handler for the particular control transaction you are sending, and that handler performs the write to the EEPROM, correct?
How are you invoking dfuWriteEeprom()? It might be easier to use the I2C interface registers directly (I'd start by verifying an ability to read the EEPROM, since there's usually some confusion about addressing due to the 'seven bits of address + one bit of R/W' confusion).
setupPacket.Request = 9;// (HID SetReport)
I use the handler code for that already in the USBModeVM105.bin EEPROM image for my I2C transfers to our codec.
Within the USBModeVM105.bin "application" source, there's a function called "void DevFunctionEntryParser(byte Cmd, void xdata *Data)" in the devSFunc.c file that handles the HID SetReport message. It will then determine the operation (read or write, I2C or SPI, etc...) do some parsing of data and perform a call to ROM code using devRomFunction(ROM_I2C_ACCESS) to complete the I2C transaction. I then use the WinUsb_ReadPipe API call to get the status of that transaction from the interrupt endpoint That the TAS "application" code sends via EP3 (I think its EP3) interrupt.
The transaction appears to complete successfully based on return values. I also verified the transaction using USBlyzer to capture the USB traffic. When I tried to read the EEPROM as you suggested, I get data but it doesn't correspond with the hex dump of the .bin image I downloaded to EEPROM. So, I assume I'm not reading from the correct location. I thought I read somewhere that the EEPROM is always at 0xA0 on the I2C bus when using the TAS1020B. Maybe not?
How are you invoking dfuWriteEeprom()?
I admit this was a hack. I took the function from the ROM code, copied to the application code and tried to write the EEPROM that way.
I read in a post you made elsewhere that there might be a step approach to reprogramming the EEPROM? Download an image to RAM and then that image performs a DFU download to EEPROM? Of course, going through the I2C registers seems to be a simpler solution.
I intend to respond to this when I climb out from a problem that another customer is having.
Since the DFU "ROM" code accessing the EEPROM uses the same I2C access function as the "Application" code I'm using to access our codec, it appears I need to understand the DFU code writing the EEPROM better. Maybe I need to duplicate more of it in the "Application" code so I can write the EEPROM when not in DFU mode. Unless someone has already found a way to access the EEPROM when not in DFU mode? I keep thinking I'm missing something basic about accessing the EEPROM using HID SetReport handler.
I'm still snowed-under, but I do know that the TAS1020B internal ROM has a bug wherein it doesn't always handle returning 'error' for a control transfer. This has to do with the fact that what should have been a 'struct' became a 'union' during code-shrink efforts. The effect is that the transaction might indicate 'success' when, in fact, it failed. I suggest that you bogus-up the HID handler to return some fixed data (i.e., not read the EEPROM, just return some bytes that you setup for testing) and see if that's what you get back. Only when that works OK should you start trying to read the EEPROM, then switch to writing.
I am able to write to the EEPROM from an application loaded from the EEPROM.
I hacked the v1.8 application to invoke
dfuWriteEeprom(0x0000, "\x00\x01\x02\x03\x04\x05\x06\x07", 8, I2C_WRITE | I2C_WORD_ADDR_TYPE );
in main(), and the data did get written to the 24LC64, overwriting the first 8 bytes of header.
As you did, I just pulled the necessary additional source from the ROM files usbdfu.c and i2c.c (and .h files) and linked them in.
Just a 'proof of concept', but shows it's possible.
This also worked:
SET_I2C(0xA0, 0x0000, 0, 0, I2C_START | I2C_WRITE | I2C_WORD_ADDR_TYPE ); devRomFunction(ROM_I2C_ACCESS);
SET_I2C(0xA0, 0x0000, "\x00\x01\x02\x03\x04\x05\x06\x07", 8, I2C_STOP | I2C_WRITE | I2C_WORD_ADDR_TYPE ); devRomFunction(ROM_I2C_ACCESS);
but you should perform the retry logic that's in dfuWriteEeprom(), and be careful not to cross EEPROM page boundaries.
Thank you, Frank! Both methods worked for me as well. I'll move forward with developing code to erase the EEPROM via Winusb/HID report calls. I think I was writing the data incorrectly (EEPROM page size). Your excellent feedback has been most helpful.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.