Forums

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

Jaroslaw,

> 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).

Regards,

Frank

Jaroslaw,

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.

Regards,

Frank.

Frank,

Yes, I am still interested.

I'll be very grateful.

Best Regards

Jaroslaw

Hi Frank,

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.

Patrick,

> 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).

Regards,

Frank

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.

Thank you,

Patrick 

Patrick,

I intend to respond to this when I climb out from a problem that another customer is having.

Regards,

Frank

Thanks Frank. 

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.

Patrick    

Patrick,

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.

Regards,

Frank

Patrick,

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.

Regards,

Frank 

Patrick,

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.

Regards,

Frank

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.

Regards,

Patrick