TAS1020B programming sequence

Curt Meyers said:

What use is the ROM code? When do I need to modify it and how do I load it?

What is the purpose of the Application code? How do I load it without wiping out the ROM code or vise versa?

Curt,

   Appendix A of the TAS1020B Data Manual explains the difference between the ROM code and the application code. The application code can be loaded via an external EEPROM or through the DFU. Either way will work.

Curt Meyers said:

Can you provide the necessary header.exe input parameters to get a device file to load and run?

The correct header .exe parameters are found in header.txt. Addditionally, you can reference the format of the header in the TAS1020B Data Manual for specific details.

Curt Meyers said:

How am I supposed to upload this application to the device if the device is running the previously uploaded ROM code, it isn't in DFU mode anymore?

The ROM code also serves as a bootloader to load the application code through either an external EEPROM or thru a USB DFU.

Does the DFU loader have to ability to program the external EEPROM? If yes, under what circumstances?

There is a DFU loader that came with the tas320aic3204 windows program and another in the firmware development, both are different. The one in the firmware development seems to be buggy should either one work?

What is the "upload" section for in the DFUTEST that comes with the firmware?

> Does the DFU loader have to ability to program the external EEPROM? If yes, under what circumstances?

This is covered in section 2.2.2.2 of the data manual.

> The one in the firmware development seems to be buggy

How so?

The ROM-based DFU in the device will not overwrite an EEPROM that has a valid application (i.e., correct signature indicating 'application').  The original TAS1020BEVM has its EEPROM in a socket, so that it can be removed for erasing/programming.

The AIC3204 EVM likely comes with a motherboard labeled 'USB-MODEVM' which is _not_ the hardware for which the FDK application was written.  The USB-MODEVM's EEPROM is soldered-down.  The utility that comes with the aic3204 evm may offer a two-step DFU EEPROM update, wherein it first loads an application into code RAM, runs it, and that application writes the DFU-downloaded image into EEPROM.  

The two host utilities expect different drivers to be loaded - that  could be your problem.

Regards,

Frank

Frank Minich said:

> Does the DFU loader have to ability to program the external EEPROM? If yes, under what circumstances?

This is covered in section 2.2.2.2 of the data manual.

So the programming is sort of non-deterministic depending on the firmware and if it detects the external eeprom, is there a way I can query this and see what it is doing through the USB interface. Could the DFU loader show what is going on as confirmation?

Frank Minich said:

 

> The one in the firmware development seems to be buggy

How so?

It appears to me that you get one change to push the download button and after that it won't work anymore. Leaving the application running after a download, I power cycle the board to make sure it is back in DFU mode and confirm by reading the status by pressing the status button, now when I press the download button it returns instantly saying done but nothing was downloaded. That seems like a bug. The work-a-round is to keep closing and re-launching the app. There are other bugs like if you check the download whole file and then check the status the download entire file box is cleared.

Frank Minich said:

 

The ROM-based DFU in the device will not overwrite an EEPROM that has a valid application (i.e., correct signature indicating 'application').  The original TAS1020BEVM has its EEPROM in a socket, so that it can be removed for erasing/programming.

The AIC3204 EVM likely comes with a motherboard labeled 'USB-MODEVM' which is _not_ the hardware for which the FDK application was written.  The USB-MODEVM's EEPROM is soldered-down.  The utility that comes with the aic3204 evm may offer a two-step DFU EEPROM update, wherein it first loads an application into code RAM, runs it, and that application writes the DFU-downloaded image into EEPROM.  

The two host utilities expect different drivers to be loaded - that  could be your problem.

I guess this is another area where I can't find any documentation. I don't know what the DFU image that comes with the tlv320aic3254 evaluation does or how it was created. I want to re-create the functionality of the TLV320AIC3254 without the national VISA  stuff. You guys told me to work with the tas1020B firmware development code because no help could be provided on the TLV320 code.

Looking at the firmware, I see that I need to change the I2C address in the ROM code to match the hardware address. I am going to change this and try again. Is there anyone that has already modified the TAS1020 code to run on the TLV320 eval board. It is a nice generic board with a TAS1020 sitting on it for the USB interface so it seems ideal for firmware development.

Here is a simple question. Is the code in the ROM directory the actual code referred to as "ROM" code in the Data Manual and sometimes called the boot loader?

> So the programming is sort of non-deterministic

Not sure what you mean by "non-deterministic".  The behavior is certainly not random.  Summarizing 2.2.2.2:

-  if the boot rom 'sees' a blank EEPROM, DFU can update the EEPROM image

-  if the boot rom 'sees' an EEPROM having only header data, DFU can update the EEPROM header data

- otherwise, DFU can only write to RAM

Note that the source for this algorithm is in the 'ROM' application.

> Could the DFU loader show what is going on as confirmation

If you have 'USBviewer' (built from the Windows DDK), you can use it to determine the 'destination', as shown in the following screen shots.

With no EEPROM:

With a blank EEPROM:

This is helpful information. It did not make the connection that code in a directory called "ROM" was the actual bootloader and extra USB helper functions talked about in the manual. It seemed plausible but not likely. There isn't a clear connection between the documentation and this code. To me it would have made more sense to explicitly point this out. The documentation could be shorter and just reference the code and it's comments. Then I could look at the actual code and read the comments to understand further. This would make it obvious that these things go together.

Second, when trying to debug something that doesn't work it is very helpful to know that the code "detected" something on the i2c bus that it thinks is memory. It would be nice to see this mentioned somewhere in the documentation although there is so much documentation I probably wouldn't have found it. Perhaps the DFUTest program would display a little more useful information.

Third, the USBMODEEVM seems like an ideal candidate to evaluate the TAS1020B. It would be great if there was code that would run on this or some instructions on how to make it run. Ultimately tying in the AIC3254 would be great. I imagine these two devices come from different divisions at TI but getting them working together would be nice since that is how it is shipped on 2 eval boards.

Is there a way to identify if the "ROM" code in the USB-MODEVM is the same as that in the firmware development package?

Is there some revision number I can access? I don't see an obvious software version in the source code.

All TAS1020B devices have the same internal ROM image.