EK-TM4C123GXL: USB Audio Device: Enumeration fails due to incorrect bLength

Good morning,

I understand now, the file usbdaudio.c is not meant to be empty! :D That was a tough one to crack! So I tried to search for StellarisWare USB library pack and since it is not accessible, I only found gitHub versions of it. I'll be playing around with this one . Let me know if you have any opinions on it and thank you very much for your invaluable help.

Kind regards,

Jan Polivka

Hello Jan,

There is still a usbdaudio.c and .h file included in the latest TivaWare, so I am not sure why you need to pull a file from StellarisWare instead.

Also I did some digging into the usbdaudio.c file and I think perhaps the issue is that the USB audio device descriptor is not properly being sent over USB.

If you look at the g_pui8AudioDeviceDescriptor, that is stated to be the device descriptor and has a length of 18 as described. While the comments don't note that it is bLength, I don't see how it cannot be. So the issue may rather be that the TM4C is not sending the data in g_pui8AudioDeviceDescriptor over to the PC when enumerating.

Now that I look at your image once more and closely from the original post, it is clear that the other bytes were all zero as well, so it just didn't send data, and bLength alone isn't at fault. Please look into how the g_pui8AudioDeviceDescriptor is being leveraged by your device code and see if you can find a reason as to why the data contained in that descriptor is not being properly transmitted to the PC.

Hi Jacob,

my .c files were empty for some reason, I think I didn't manually install the USB library but that's fixed now.

I think I've managed to recreate the problem but for a bulk device. At least I have something to hold on to, so I'll figure that out and see if it helps with the audio example.

Best regards,

Jan

Also, comparing the example bulk device and my edition of bulk design, I am missing UART completely (on purpose). Is it a valid theory that the reason why it doesn't get enumerated properly is because there is no protocol (UART) that would relay the information?

Hello Jan,

No missing UART should not affect enumeration. The idea of the UART configuration to send messages to the PC from the LaunchPad (and sometimes receive as well) and while that occurs over USB via LaunchPad ICDI it has no bearing on the enumeration, so you don't need to worry about that.

Good morning Ralph,

You were right, UART is not required. What I did just now was to copy all of my DIY files for a bulk device into the example bulk device, getting rid of the provided code. Lo and behold, TIva gets enumerated properly! Right now, I feel like the real issue is library linking, so it's what I am going to look into now.

Best regards,

Jan

I looked up linking and what not, tried to reconstruct the example blinky, linked everything and the example blinky worked. Did the same for my bulk device and it did not help. The somewhat infuriating fact is that the compiler does not give any warnings or errors.

Hello Jan,

Are you trying to make your own CCS project? If so, why not just reuse a TivaWare example, rename it for your purposes and add in your own files etc.? That is how most customize their projects and it's far easier than trying to link in everything needed correctly.

Though a lack of warnings or errors is a bit curious... are you using CCS? If something isn't linked correctly then I would expect a build error as an API would not be able to be found or a header file isn't accessible etc.

Good morning,

I initially tried to build on top of the bulk device example (there is no audio device example, so I couldn't start there) and I ran into the issue that I was describing earlier (bLength issues). I decided that I would recreate the bulk device example, maybe I would learn something useful. The code itself works but not within a new project, I'll attach snaps of what I am linking and the paths, see if you can find the issue? I could post the project folders, if helps.

Best regards,

Jan

Jan_Polivka_TIva.zip

Hello Jan,

It looks like one of the files you are trying to link in via the Linked Resources option is the usbdbulk.c file. I don't agree with trying to do that as you are just linking in an absolute path to one usblib file, but not the whole usblib. Why did you take that step? If it was to resolve issues with functions not being found, then I don't think you addressed the root cause right.

Also I don't get why there are so many links to TivaWare libraries. Linking C:\ti\TivaWare_C_Series-2.1.4.178 makes sense, but I wouldn't add in additional include paths for usblib and driverlib. Rather just have C:\ti\TivaWare_C_Series-2.1.4.178 linked and then use our method of navigating folders with the #include calls such as #include "usblib/device/usbdbulk.h" for example.

Hi Ralph,

I absolutely agree, it is a bad idea. Including only TivaWare folder was what I had done initially and it did not help, so I tried to add more, see if it helps as I have nothing to lose.

Best regards,

Jan

Hello Jan,

I would undo those steps and also remove the Absolute Path to usbdbulk.c and then if you get any build errors, please post them, otherwise it is not possible to help.

I still think your best means to succeed is just rename a TivaWare example and change it to your needs so all the linking is right.

I did change it and it had no effect, no errors whatsoever. I unfortunately cannot devote any more time to this at the moment, I am sorry for wasting your time.

Best regards,
Jan