CMX/ColdFire USB Stuck In Loop(s)

[lolachampcar]

I am using a JM128 and have found two instances where the CMX code will hang in a loop.  One example is in Host mode performing a read when the client has no data.  The device hangs in this loop     while((MCF_USB_INT_STAT & (MCF_USB_INT_STAT_TOK_DNE | MCF_USB_INT_STAT_STALL | MCF_USB_INT_STAT_ERROR)) ==0)    {
as neither a Token Done, Stall or Error event occur.

I've added a timeout which lets me exit (similar to a pipe policy timeout on a WinUSB read) but I have yet to add any USB SIE clean up code.  Specifically, I've not found any reference to "turning off" or terminating a pending Token in the data sheet.

I assume I must write something to the Token register (although the data sheet says only IN, OUT and SETUP Tokens are valid) then clear the own bit for the descriptor in question.  However, you know, when you assume you make a ...........

Has anyone had the need to terminate an active token?  If so, can you share how you went about cleaning up the USB SIE once you timed out?

I've had a similar problem with IN transactions in client mode where I get stuck in a waiting on client Tx to complete.  I got past this problem by nuking the client services all together which is a bit silly but it worked.

Thanks,

Bill

[RichTestardi]

Hi,

I doubt this is the only way to do this, but for the host case where the device NAKs when it has no data, then you can turn on the RETRY_DIS bit in the endpoint, like you'd do for an interrupt endpoint, and then you'll receive a TOK_DNE for each NAK, and you can gracefully decide when to give up, with the BD no longer owned by the SIE.

This is also a good debugging method to tell when you're getting infinite NAKs back from a device (which I assume is happening to you!!!).  Note that it does have a slight performance impact on devices (like many) which intentionally return one or two NAKs in the normal sequence of processing a request, as the retries happen more slowly when initiated by sw.  So you might want to do this only on endpoints with the issue (no data indicated by NAK).

-- Rich

[lolachampcar]

Rich,

I can not thank you enough.  That one post was more help then I've gotten from the guys that own the silicon in a month!

I needed a pipe timeout so I extended the retry by one for every NAK as long as my timer was running.  Once the timer expired, I let it retry out and return gracefully.  I now have a pipe timeout without a hung SIE.

Thanks Again,

Bill

[RichTestardi]

You're totally welcome -- glad I could help!

I also have source code posted for my dual-mode (host/device) USB driver in sources/usb.[ch] contained in "skeleton.zip" from the page:

  http://www.cpustick.com/downloads.htm

There are 51jm128 as well as 5222x and 5223x projects there.

I opted not to use CMX, and instead built my USB driver from scratch, after encountering a few problems early on with host mode functionality.

I figure it always helps to have more examples of how folks do things, so I post it all. :smileyhappy:

-- Rich

[TurboBob]

I am currently using the MC9S08JM60 in my first USB enabled project.  I have successfully (so far) managed to get the CMX stack to run in a Processor Expert created project.  (Generic HID mode)

However I am still on the steep part of the USB learning curve,  and am worried that things like the subject of this thread are going to bite me when I least expect it.

So,  have any of you used the 08JM USB CMX stack?  If so does it suffer a similar bug?  How similar are the MCF51 and 9S08 flavors of the CMX code?

I am contemplating trading up the the MCF51JM in order to benefit from the colective wisdom here in the land of 32bits...     The MCF would be overkill for my application though.

At any rate,  thanks for your attention.

Bob Bailey

N8DRK

[RichTestardi]

Hi,

From a cursory look at the .c files, it seems the 9S08 drivers are quite different from the 51JM128 and 52223 drivers, which are similar except for what seems to be some requisite interrupt and pull-up differences.

The hardware on all three chips seems similar (based on the old TDI/Chipidea/MIPS USB FS core, I think someone told me?), though the 9S08 is non-OTG, right?, so that is one difference to be wary of.

I actually ported my USB driver to the PIC32 yesterday and today, with almost no effort (just interrupt and pull-up changes, again) -- but that was a move from an OTG to an OTG USB core, which I believe are identical...

-- Rich

Message Edited by Rich T on 2008-12-31 05:56 PM

[TurboBob]

Thanks for the reply.  You are correct,  the 08 USB has no hosting capability or OTG.

I ordered a MCF51 chip for my demo kit ( I have a really early JM kit),  I want to play with porting my 8 bit code 'upwards'. 

I need to spend some time poking thru the CMX code to understand what's going on.

After all these years working with 8 bit machines,  it will be fun to see what the same code will do in a 32 bit machine. 

Regards,

Bob

[RichTestardi]

I think you'll love the 51JM128.  If you want more sample code for it (accessing flash, peripherals, etc.), I have some on that link above.  And I'm always happy to help by e-mail (rich@testardi.com).  Good luck!

-- Rich

[echarry]

Hi Rich T,

It seems finally I have someone who could give me directions =).

I am also in the steep learning curve of the USB protocol and hence, I am struggling since never before.

I've used the 9SO8JM to sample a couple of analog signals and send these data through the USB port to a PC. It worked fine and I displayed the raw/processed signals with Labview.

However, as we know, the S08JM doesn't have USB host capabilities. This is a drawback for us, as  we intend(ed) to port that code to the MCF51JM, as it has a USB host controller and it is supposed to be connected to PDAs/Pocket PCs (well.... at least the A/D conversions can still remain). The majority, as far as we are concerned, are USB clients only.

Hence we need to move on to the CMX  host stack for the MCF51JM. They have two projects: the mass storage and the HID class device drivers only. We thought that, as the PPC is treated as a mass storage device, it should have an interface with the class code correspondant, and the endpoint descriptors. Which doesn't happen! The ifc_desc returns zero interfaces and the device is not properly configurated.

Anyway, I was wondering with your experience, do you think it would still be quicker to keep tweaking those examples around and make the enum/configuration work (although we are not sure how to finalize the conf. process), use the processor expert or use the skeletal code you have in your website (which btw didn't come with the 51jm128.mcp)?

Any kind of information is appreciated, as you probable see we are kind of lost...

Thanks for the time of reading this huge message!

Edgar Charry

[RichTestardi]

Hi Edgar,

If you download this:

  http://www.cpustick.com/downloads/skeleton.zip

The first file in the zip should be 51jm128.mcp, and if you open that with CW6.2, it has a full host mode USB driver that we have used to talk to flash drives, etc. -- you want to build the "Skeleton 51jm128 target".

The trick is you have to set "usb_host_mode" to true before you call usb_initialize() to get host mode functionality turned on.

Then you should be able to see that "scsi_attached" gets set true when you connect a USB mass storage device.

Are you using a DEMOJM board to test this?  If so, you also have to do some jumper configuration to turn on the 5V USB power -- we were using custom HW which was different than the DEMOJM in that regard.

We found in building a portable encryption unit that the CMX host stack worked with maybe 40% of the memory cards out there -- many have different initialization requirements, and if you don't follow them exactly, they don't talk.

You can see where we ended up in the the attached file (which is not in the public zip archive), which implemented the block level caching (and memory card initialization which is critical).

Basically, when we were done, our code worked with >20 memory cards and close to 10 digital cameras, which all expose mass storage interfaces, so we think it is pretty robust now.

I should be around all weekend and next week, so feel free to return with questions or whatever.

-- Rich (rich@testardi.com)

PS we also have fat32 code adapted from here http://www.larwe.com/zws/products/dosfs/index.html which I can (and have :smileyhappy: mailed you, which is not appropriate for me to republish here.

Message Edited by Rich T on 2009-01-30 10:03 AM

[DMV]

See post

https://community.freescale.com/message/78726#78726

[lolachampcar]

Edgar,

One of my goals was to use "generic" WinCE devices as Clients to the JM128 (in Host mode).  The goal was to use inexpensive devices like some of the GPS navigation units as a hand held user interface to our products.

This part of the project has turned out to be the most difficult.  Here were some of the major barriers-

(1) most CE devices in USB Client mode use ActiveSync or a proprietary protocol to communicate across the only port on the device, the USB port.  You will need to manage that process so as to claim the USB port for your needs when needed.

(2) using ActiveSync was not an option as it is undocumented

(3) if you use existing CE "appliance" type hardware like the GPS units, you will need to "hack" your application into the existing boot structure.  Your hack will need to disable (and enable if need be) the above mentioned ActiveSync support.

(4) once you are "in" and your application is running on the CE Client and you have USB access, you will need to craft your USB structure with the JM128 being the USB Host and initiating all communication while the CE Client will actually be the one initiating activity.  We did this by having the JM poll the CE device for commands.

(5) we needed the JM device to still act as a Client and thus needed the ability to intelligently recognize who was connected and act appropriately.  Our solution consisted of a host and client connector on the JM device of which only one could be connected.  Client was detected by the presence of Vusb while we polled for Host.  We found this worked better than trying to fit the OTG model to our environment.

We continue down this path as there is no way we can build a 4.3” color TFT touch screen user interface for the $100 price points you can find out of China.  If your project permits, you may want to consider building your own hardware using one of the ARM development platforms which come with all the necessary CE (and Linux in some cases) board support package to build your custom operating system with USB Host support.

I hope the above is of some help.

Bill

[TurboBob]

thanks, 

I browsed your site and app notes,  I will give it a try next week once my chips arrive.

Bob

Message Edited by TurboBob on 2009-01-01 06:13 PM