TMS320C5515 USB, SET DESCRIPTOR request

It is not possible for the CSL to fully implement all USB requests, simply because the details are different for every device. It is up to you to provide this function.

If you look carefully into the source code provided for the USB examples, you should find the central routines that analyze the request type and call out to various specific subroutines. Once there, you can add a line of code to call your own implementation of Set Descriptor.

I have certainly implemented Set Configuration and Set Interface for my Device, so I know that it is possible and functions correctly. I have not tested my own Set Descriptor, but it is the next item on my to-do list.

Hi Brian,

> It is not possible for the CSL to fully implement all USB requests, simply because the details are different for every device.

I'll dissagree with that opinion of yours.

The specific CSL, is meant to be for the same family C55x4/x05 which they all share the same USB controller, there are no differences between them in that regard.

I understand that the CSL is a work in progress at the time, so I'm not arguing for that in my initial post, (eg why its not in the CSL), I'm just asking to see if there is any solution that I might missed.

Also, wondering why its not in CSL and at the same time, I also couldnt find myself an easy solution to it, so it might has a catch somewhere.

I also have implemented some sort of solution, yet it was not behaving ok so trying to see what is going on.

The actual issue is that the control endpoint transfers, specifically those with an additional data phase, with direction from host to device, seem to read the setup packet but not the data packet, whereas for the other direction, device to host, everything is ok so setup and data packets both pass through ok.

Christos Nikolaou12204 said:

The specific CSL, is meant to be for the same family C55x4/x05 which they all share the same USB controller, there are no differences between them in that regard.

When I said "different for every device," I was referring to USB Device as defined in the specifications. In other words: Mouse, Keyboard, Storage, Networking, etc. In other words, each Class of USB Device is going to need unique code. I was not trying to say that the source would change for each DSP. If you have the wrong USB source for your DSP, then basically nothing will work.

Also, wondering why its not in CSL and at the same time, I also couldnt find myself an easy solution to it, so it might has a catch somewhere.

Unfortunately, USB is not easy. You need to read the entire USB CSL documentation from Texas Instruments, along with the entire USB hardware documentation for your DSP, then you have to read the entire USB Specifications including any additional documents for the Class of USB Device that you hope to implement. However, once you understand all of the pieces, it is not too difficult to synthesize new functionality that might be missing from the examples.

The actual issue is that the control endpoint transfers, specifically those with an additional data phase, with direction from host to device, seem to read the setup packet but not the data packet, whereas for the other direction, device to host, everything is ok so setup and data packets both pass through ok.

Look for an example of host-to-device for Bulk transfers, and try to implement something similar in the Control subroutines. I have been able to get additional data phase transfers working from host to device for the C5506, but it took a lot of sleuthing and additional code on my part. There was no direct example of this in the existing code. I assume that the C55x4/x5 USB examples are similarly terse. You do have a slight advantage because there are more examples for your DSP than the C5506.

Look for an example of host-to-device for Bulk transfers, and try to implement something similar in the Control subroutines. I have been able to get additional data phase transfers working from host to device for the C5506, but it took a lot of sleuthing and additional code on my part. There was no direct example of this in the existing code. I assume that the C55x4/x5 USB examples are similarly terse. You do have a slight advantage because there are more examples for your DSP than the C5506.

Yes, I've already implemented a working C5515 firmware for a marketed device of mine with high Speed USB streaming and eveything is ok. Its just that I needed this additional functionality recently and I have to find a solution.

So far my implementation for Set Descriptor works but with a bit of 'hardwiring', having some kind of fixed delay between the setup and data phase and that comes from a plain delay loop so its not optimal at all (though that is the only way so far that I managed to have it working), thus I'm trying to find a better one if it exists.

I believe that the C5506 USB is different from your C55x4/x5, so I will describe what I did at a high level, and hopefully you will find similar functionality in your USB CSL.

Individual USB request functions use return codes like USB_REQUEST_DONE, USB_REQUEST_STALL, USB_REQUEST_GET_ACK and USB_REQUEST_SEND_ACK. Looking around the sources, I realized that I needed to return USB_REQUEST_DATA_OUT in order to make the host to device data transfer happen. I may have needed to fill in some missing code elsewhere in order to complete the design pattern started in the example sources. There are quite a few comments in the USB sources for my C55xx family USB, but you still may need to fill in the gaps.

To respond directly to your concern, I did not code any sort of delay, and certain not a plain delay loop. I have two Isochronous endpoints transferring data on every frame, so I cannot afford to block the CPU anywhere. Instead, it seems that the USB examples use a state machine with specific #define'd values for each stage, including a specific state for "waiting for the addition data transfer in a host to device message."

I have not looked at any USB examples for the C55x4/x5, so I won't able to confirm whether the existing code there is designed the same way. Hopefully you can find what you need if you're looking for the right thing.