TAS1020B Firmware Example TSC2100_FW8 doesn't work

Dieter,

What hardware are you running this on?

Regards,

Frank

Hi Frank,

The hardware is our own prototype. To exclude any hardware problem, I have ordered the TSC2100EVM for further tests (but not yet received).

Anyway, the delivered APP8.BIN runs on our HW but the build APP7.BIN doesn't work.

Regards,

Dieter 

Dieter,

You mention "the delivered APP8.bin".  I do see that in the TAS1020B Firmware Development Kit, without any source files.

Then you mention APP7.BIN.  I don't see that in the FDK, nor do I see a project which would create a bin by that name.  I see app116 and app124, but no app7.

Am I missing something? 

Does your hardware use an AC97 codec or I2S codec or what?  If the former, can you build app116 and see what happens?

Do you have an EEPROM attached to the TAS1020B in your prototype?  I assume not.

If you have no EEPROM, please take a look at your bin file using a hex editor and compare the content of the header bytes to Table 2-1 (in particular, the 'Attributes' byte) - you may want to run the header.exe utility to mod header.txt before building the final image.

Regards,

Frank

Frank,

>I do see that in the TAS1020B Firmware Development Kit, without any source files.
That's my problem. I dont' know how APP8.BIN was built because I haven't the sources.

Target 'WM9707 (TAS1020A) in App.Uv2 creates APP7.BIN:
RunUsr 1 1 <C:\Keil\C51\BIN\Header.exe HEADER.TXT TEMP.BIN APP7.BIN>

Our HW uses I2S (not yet connected).

>If the former, can you build app116 and see what happens?
app116 is in TAS1020BEVM Firmware\v1.8\Application - not TSC2100_FW8.
I have tried all settings of TAS1020BEVM and TSC2100_FW8 without success.

Currently I have no EEPROM. But with EEPROM I got the same problem.

I have already verified the header with the header.exe utility and performed some tests with different header configurations. I have also used the extracted header from the APP8.BIN without success.

Regards,
Dieter

Dieter,

Ok, I see now how you got where you are.  I too don't have access to the particular build source that would produce app8.bin.

I suggest approaching this in smaller steps.  Do you have a GPIO that you can wiggle and observe?  If so, first build an app that does that, and verify your ability to download it and start it running.

Then, remove all the SPI stuff from TSC2100_FW8, and remove any CODEC calls.  Then build that and see if the descriptors show up.

Do you have a USB sniffer, so you can check to see if the host gets _anything_ back from the TAS1020B?

I've done all of my work with the v1.8 application in the FDK, so the TSC210_FW8 app is new to me.

Regards, 

Frank

Frank,

I tell you sometinhing about what I have all done:

I have eight LEDs connected to port 1 for debugging.

My first attempt was with the v1.8 application. I have removed all SPI and CODEC stuff and the HID descriptor. Then I have added some commands to switch my debug LEDs at different locations in the code. I was able to build and download the modified v1.8 applications and to start it. Main() and devUserIntHandler() are called several times (checked with the LEDs) - BUT: DFUTEST.EXE reports always different errors after I pressed the reset button and the USB device enumeration fails always. I have tried several configurations (in the sources and with the header, with EEPROM and without it).

Then, I have compared the v1.8 application with the TSC210_FW8 applications. I was wondering about the different reset handling in the examples. I have modified devSleepModeOn(), devCheckReset(), devUserIntHandler() in my application according the TSC210_FW8 one because I had the assumption that something was wrong with the reset code. No success, I got the same problems.

Then I have switched to the TSC210_FW8 application because I found out that the shipped APP8.BIN works with my HW. I have done a lot tests with the different target configurations, with different switches and compiler settings - without success. No built APP7.BIN was able to enumerate the USB devices (TAS1020B) with success after the reset.

I have compared (with araxis merge) the shipped APP8.BIN with the 'WM9707 (TAS1020A)' target. The binaries have nearly the same size and have some identical parts so that I assume the APP8.BIN was built with the TSC210_FW8 sources (but what about the switches compiler settings and so on?).

Today, I'am out of the office. I hope I will get the TSC2100EVM evaluation board soon to test the APP7.BIN with that HW - or is it possible that you perform some tests for me at the TSC2100EVM evaluation board (e.g. with the actual Keil compiler)? Is it possible that there is a compiler problem with the Keil C51 compiler V9.05?

We have a USB sniffer but I haven't used it until now. I'am not so familiar with USB. If I got the TSC2100EVM evaluation board and still have the same problems, it must be a compiler issue, the TSC210_FW8 example is buggy or ??? Have you anny assumption what's going wrong?  

Do you know the meaning of the _815E_FIX_ switch used in the TAS1020 examples?

Which one is closer to the TAS1020B - the TAS1020 or the TAS1020A? I'am not aware about the differences. Are the examples only tested with TAS1020 and TAS1020A and not appropriate for the TAS1020B?

Thanks for your assistance!

Greetings,
Dieter

Dieter,

When you boot the TAS1020B with no EEPROM, or a blank EEPROM, it comes up as a DFU-only device with idVendor = 0xFFFF and idProduct = 0xFFFE, so dfuusb.inf will load DFUUSB.sys.  Once you load your application and reboot, Windows no longer sees a USB device with that combination of idVendorId and idProduct, so it won't load DFUUSB.sys.  So, I wouldn't worry about anything that dfutest.exe indicates after the restart.

I don't think it's necessary to worry about reset handling if the host PC is not able to read the device/configuration descriptors.  I would like to suggest that you go back to the v1.8 version and build app116 after commenting-out any writes to the codec.  I intended to do that today, but ran out of time.  If you don't get something going by tomorrow, I'll try this here.

I have heard of some problems using uVision4 - is that the tool you are using?
cl51 indicates
C51 COMPILER V8.18 - SN: C1REC-SA6L9U
COPYRIGHT KEIL ELEKTRONIK GmbH 1987 - 2009
a51 indicates
A51 MACRO ASSEMBLER V8.01 - SN: C1REC-SA6L9U
COPYRIGHT KEIL ELEKTRONIK GmbH 1987 - 2007
lx51 indicates
LX51 LINKER/LOCATER V4.39 - SN: C1REC-SA6L9U
COPYRIGHT KEIL ELEKTRONIK GmbH 1995 - 2009

Use TAS1020B settings in preference to TAS1020A settings;  use TAS1020A settings in preference to TAS1020.

Tell you what:  please build v1.8's app116 in your environment (with default settings from the FDK) and send me the resulting app116.bin.  I'll see if it runs on this EVM.

Regards,

Frank

Frank,

My uVision4 Environment:
C51 COMPILER V9.05 - SN: C1NEC-VACFYE
COPYRIGHT KEIL ELEKTRONIK GmbH 1987 - 2011
A51 MACRO ASSEMBLER V8.02a - SN: C1NEC-VACFYE
COPYRIGHT KEIL ELEKTRONIK GmbH 1987 - 2008
LX51 LINKER/LOCATER V4.56 - SN: C1NEC-VACFYE
COPYRIGHT KEIL ELEKTRONIK GmbH 1995 - 2011

Here my built APP16.BIN without any sources, header or configuration changes (renamed to APP16.BIN.txt to get it there, hope this works).
1805.APP116.BIN.txt

I can download it to my HW, but after reset, the device enumeration fails. See attached screenshoot from UsbView: 1464.failedUsbEnum.doc.

Regards,
Dieter

Dieter,

I pulled-down your file 1805.APP116.BIN (it looks to have size 5640 Bytes, and I looked at the header using a binary editor and it looked OK, so I think your technique worked) and used DFUTEST to load onto a TAS1020BEVM.  When I did a reset, the WinXP host PC would not enumerate it.  I attach a USB traffic capture here:

So, the hardware does ack the setup packet, but never sends a response with Device descriptor data.

There have been rumors on this forum that builds performed using uVision4 do not work.  Possibly, Keil changed the calling conventions, so that linking to the ROM image (built using older tools, obviously) results in problems (this hypothesis may be completely wrong, but would be consistent with this behavior).

Investigation of compatibility with uVision4 now goes on my to-do list, but I don't think it will be resolved immediately.  Can I ask you to revert to uVision3 to see if the problem goes away?  Thanks very much for bringing this to my attention in a powerful way, and sorry for this inconvenience, but I suggest that, if you want to make progress in the short term, you use older tools.  Here's what I'm using:

 Best regards,

Frank

Frank,

interesting news.

Because we have only the current uVision4 CA51 compiler kit, I have sent a support request to Keil to provide me the older uVision3 version that you are using.

Thanks for your support!

Greetings,
Dieter

Dieter,

So, not available via their web site?

Frank,

thanks for the hint that I can download older versions. I wasn't aware of that.

Now, I have downloaded and installed uVision3 V3.8, but during compilation of the v1.8 application I got the following linker error:

******************************************************************************
* RESTRICTED VERSION WITH 0800H BYTE CODE SIZE LIMIT; USED: 14ACH BYTE (258%) *
******************************************************************************
Program Size: data=104.1 xdata=46 code=5622
LINK/LOCATE RUN COMPLETE.  0 WARNING(S),  0 ERROR(S)
*** FATAL ERROR L250: CODE SIZE LIMIT IN RESTRICTED VERSION EXCEEDED
    MODULE:  C:\KEIL_UVISION3\C51\LIB\C51S.LIB (-----)
    LIMIT:   0800H BYTES
Target not created

The Keil support told me that it should work and is now examining my problem.

Regards,
Dieter

Frank,

now, my uVision3 V3.8 works.

I have compiled the v1.8 application APP116.BIN without any changes but it doesn't work with our HW. I got the same problem. I'am able to download and reset the TAS1020B then the USB enumeration fails.

Meanwhile, I got the TSC2100EVM eval board.The board works fine with the firmware from the onboard EEPROM. But when I download the self built TSC2100_FW8\Headset firmware (APP7.BIN) I run into exactly the same USB enumeration problem - regardeless if I compile with uVision3 or uVision4. The APP8.BIN, shipped with the TI firmware package, runs with success. Therefore, I ask again: don't know anyone how it was built?

If I download the APP116.BIN to the TSC2100EVM eval board, the device is still recognized at a DFU device after reset but doesn't react on any further DFUTEST command.

Attached, you will find my APP116.BIN, built with the uVision3 compiler (same versions as your screenshoot indicates).

0724.APP116.BIN.txt

Please, can you verify it on your TAS1020BEVM eval board?

Could you build a APP116.BIN with your compiler from the original TSC2100_FW8\Headset sources for me? Then I would try it on my TSC2100EVM eval board.

Have you any suggestion how I can proceed to locate the problem?

Regards,

Dieter

Dieter,

> Meanwhile, I got the TSC2100EVM eval board.

I'm not sure I've got the same board as you do.  What does the silkscreen say that the name of the board is?

> Attached, you will find my APP116.BIN, built with the uVision3 compiler (same versions as your screenshoot indicates). ..  can you verify it on your TAS1020BEVM eval board?

I burned it into eeprom, and the board behaved just like yours does:  no enumeration.

> Could you build a APP116.BIN with your compiler from the original TSC2100_FW8\Headset sources for me? Then I would try it on my TSC2100EVM eval board.

I will do this just as soon as I am able.  I apologize for this being such an undertaking.

Frank

Frank,

my evaluation board:

The *.LST files of the TAS1020 example firmware indicates the following compiler version:
"C51 COMPILER V6.03 DEVICE 10/13/2003 10:57:56 PAGE 1"

I have asked Keil to get the C51 V6.03 compiler to make a test with this version. Unfortunately, the V6.03 compiler requires a dongle to operate and the dongle is not available from Keil.

Is it possible to include the sources of the ROM firmware into my firmware so that the ROM code is not used to operate the TAS1020B? This would eliminate any calling convention problems between the ROM code and my firmware. But I'am not aware of overhead (development time, binary size). What do you think about that workaround?

Regards,
Dieter

Dieter,

I've been successfully using C51/CX51 version 8.18 when building TUSB3200A applications (which obviously do not utilize an internal ROM).  However, when I tried using same for TAS1020B applications, I got the same result as you.  I had updated back in the March timeframe when I had a disk crash.

I have now gone back to C51/CX51 version 8.08, and the bin I build from the v1.8 application does work.  Could you please try that version of c51/cx51?  I've built the TSC2100_FW8 app and posted here: 5342.app7.bin.zip - it's built for EEPROM:

It's very difficult to _not_ use the internal ROM functionality of the TAS1020B, since the TAS1020B has reduced program RAM (relative to the TUSB3200A, for example).  If you have to add all that code to your image, things are going to get very tight.

Regards,

Frank