RM48 USBD Mass Storage

Nathan,

The TivaC library will take you pretty far but be aware that the underlying USB device peripheral is different.
I think the Tiva uses the mentor graphics OTG controller (not 100% sure, didn't work on it) but the Hercules uses the
USB device from older TI parts like OMAP5912.

So I would expect to find differences at a low level between the two controllers. I'd start by looking at what causes NAK
to be emitted by the USB device controller on Hercules and from the TRM that is:

"The transaction non-acknowledge (non-ISO) bit only concerns non-ISO endpoints with
SYSCON1.NAK_EN bit asserted. This status bit is set at the end of a transaction if a NAK
handshake is returned to the USB host, and if no non-handled interrupt is pending on the
current buffer. The USB core automatically returns a NAK handshake to the USB host if a
valid IN token is received by a TX endpoint or if a valid OUT transaction is received by an
RX endpoint, and the STAT_FLG.FIFO_EN bit is not set for the endpoint. The bit is cleared
when the USB device controller has finished handling the corresponding interrupt (at
EP_NUM.EP_SEL bit deselection)."

-Anthony

So, I mention the 5912 because you may get some hints by looking at
www.linux-usb.org/.../h2-otg.html
And 'omap_udc' on that page.

The omap5912 was in a lot of ways more complex but the underlying way of working with the USB devices' FIFOs and
control registers should be the same.

Anthony,

First off, thank you for the quick reply. Your answer provided me with some great information, and you're very right about being aware of the differences of TivaC vs Hercules. I have seen vast differences, and I think trying to translate to the rm48 is proving difficult, but I'm determined to get it!

Either way, I have a couple more questions if you don't mind. Regarding the STAT_FLG register, that paragraph you posted says that the core could be sending the Host a NAK packet if my TX EP (or RX EP) receives an IN (or OUT) packet, how would this happen? Am I able to just enable the fifo for those endpoints and try to read the SCSI CBW from that? or is there a way to avoid this from happening?

Thanks again,
-Nate

Hi Nate,

So, I would refer you to the flowcharts in the TRM chapter section 29.3.10 "USB Device Interrupt Service Routine (ISR) Flowcharts". As far as I know these show you exactly what to code in your interrupt handler.

I think for the data transfer to EP1 you'll wind up in those 'Non-ISO, Non-Control IN/OUT Endpoint Transmit/Receive Interrupt Handler" flowcharts down in section 29.3.23 and 23.3.24 but not 100% sure. These do show you where to write to the "SET_FIFO_EN" bit that the status flag talks about.

What I was thinking is that you might find some code for these flowcharts buried in the OMAP linux work online, that you could refer to in order to understand this section better.

Unfortunately I've never written code for this particular USB device myself (long story) but I've used the mentor OTG controller. So I can help you but I'll be navigating the docs in parallel w. you.

I believe though that I did use a mass storage class example from Micrium on this device once to do some electrical testing. So you could also look at getting this (commerical) code from them if you need something quick.

Otherwise, if you're coding from scratch, I'd suggest spending a lot of time with those flowcharts and also making sure that you have all of them implemented (not just some of them) because as a device you don't have control of what transactions the host initiates, so you want to make sure you've got all the event handlers in place.

Thanks and Best Regards,
Anthony

Anthony,

Fantastic, thank you for the reference and the information. I will definitely take a look at the ISR flow charts and see what I might have missed. I'm sure I'll have more question in the future, but thank you so much for your responses.

Best,
-Nate

Anthony,

After checking both bulk EP FIFOs, they look like they are being set/cleared correctly. I am currently using a USB Analyzer that is returning interesting results.

When the first Inquiry CMD is sent fro the Host to my device, it is sent as an OUT transaction (expected) and sent as a DATA0 packet. It is read, and responded to correctly by my device (Data and Status IN Transfers both get sent and accepted). However, the very next OUT transaction is sent as a DATA1 packet (I believe this is part of data toggling), and immediately my device starts sending NAK transactions. How can I avoid NAK-ing this data toggle? (Again both endpoint buffers seem to be set/cleared correctly).

Thanks,
-Nate

Hi Nate,

It's pretty normal for the host to toggle the PID between DATA0 and DATA1 so I'd be surprised if the usb device can't handle this.
But at the same time I can't tell you that I've used this feature either.

I believe this is the demo I used before when testing the signal quality on the USB device:
www.micrium.com/.../

There is a USB Mass Storage Class device demo embedded in there. Why don't you download the demo and try it out?
It would at least be interesting to compare against you own setup especially if you have a USB bus monitor.
And you may also want to consider purchasing this SW from Micrium if you find it works well out of the box.

Anthony,

The demo worked well, unfortunately wasn't able to figure out my problem from it. Still failing when the host sends the Inquiry command for the second time. Why would I not be able to receive another out packet after i successfully received and responded to the first one on the same endpoint?

Also, I have some general questions about RM48:
1. Why use USB 1.1? Why not upgrade it to 2.0 when you designed this board?
2. What's stopping me from upgrading my USB Device port to >= 2.0? Is it mostly hardware or software?

Thanks again for your help,

-N8

Hi Nate,

I don't know what's going wrong exactly with the Data0,1 toggle issue; the only thing I can recommend is to either consider licensing the working driver (it may wind up costing a lot less to purchase from a vendor like Micrium than develop your own) or dig into the details and at least you can be confident that the hardware works given you have something working to compare against.

For 1.1 v.s. 2.0 - if you mean Full Speed v.s. High Speed [or even now super-speed] the higher speed USB peripherals require larger and larger blocks of silicon for the physical interface. Full speed doesn't add much more than a special IO cell to the device but high speed adds a fairly large phy and superspeed is even more complex... These phys require components that were not available in the process in which Hercules was designed and it was a late requirement addition to support USB - so full speed was the best we could squeeze in.

If you need high speed USB you should probably look at a different processor family because even if you were to add a high speed USB external device to your system the next problem you would have is interfacing that to the memory on the Hercules. The highest bandwidth interface we have is EMIF but that is a bus master only - whereas an efficient high speed USB peripheral will likely be implemented with bus mastership capability and there won't be a clean way to interface it with a Hercules.

A device in the Sitara family would be more appropriate if your main concern is high speed USB...

-Anthony