9S08JM60 USB issues with HID mode

[TurboBob]

I have been trying to implement HID mode communication with my project.  The PC side seems to be operating fine, but for some reason I am getting corrupted data coming out of the JM60.  It seems to happen when the PC and JM are trying to communicate at the same time.

In watching the USB comms using a sniffer program,  the data going to the JM is ok,  but some of the OUT data is showing up in the IN data.  Its not consistent.

The OUT data is going on on endpoint 0,  the IN data is on endpoint 1 (81)

Do I need another endpoint to separate the data properly?  Or do I just have an error in my JM60 code?

I did make a small change to hid_process() so the software would not have to wait.  It is shown below,  perhaps my logic is flawed.

I am attempting to send 64 bytes every 100 ms.  hid_process() is called in the main endless loop.

Code:

/***************************************************************************** * HID_process ****************************************************************************/void hid_process(hcc_u8 id)      ////  !!!!! modified for ONE IN Report{                                //  poll this function quickly                                //  this function will lockout further                                  //  sending until the prev. one is gone.static char tempcharHID;                                     if (usb_get_state() != USBST_CONFIGURED)  {    return;   }    tempcharHID =  usb_ep_is_busy(HID_IT_EP_NDX);  if(USB_BusySending == 1  &&  tempcharHID)    {    // if busy sending, exit    return;    }  else    {     USB_BusySending = 0;    }// if report is pending, send it. set busy flag      if(reports[id].used        && reports[id].pending            && reports[id].type==rpt_in)    {      usb_send(HID_IT_EP_NDX, (void *)0               , reports[id].buffer               , reports[id].size               , reports[id].size);//      while(usb_ep_is_busy(HID_IT_EP_NDX))//        ;      reports[id].pending=0;      USB_BusySending = 1;//      break;    }}

[Goz]

Hi TurboBob I have been working on exactly the same thing as you, but I keep having an issue with the MCU not sending the data out reliably. Sorry to hijack your thread, but maybe you might have an answer.

The problem I have is that even though the data I am sending is in the right location and the report descriptor is set up correctly, when ready_ep_tx(ep, 0) is called in usb.c the USBRSTF bit in the INTSTAT register is being set. This then stops the data being sent out and the USB reset event is called in the interrupt routine.

I have checked all of my buffer sizes etc and altered various values in the stack firmware but this issue keeps bugging me. I have also got my USB device set up exactly like yours, 1 defined endpoint with the OUT at enpoint 0 and IN is endpoint 1 set at address 81.

The documentation doesn't seem to be very clear about how you set up multiple endpoints, although I feel that some experimentation is in order.

[TurboBob]

all of my problems have been due to descriptor settings and stuff like that.  The core CMX code has not given me any troubles with the exception of the change to Hid_process noted in my first post.

Perhaps post some of your code.

Are you using Processor Expert?  What version of codewarrior are you using?

What are you using to test the USB functionality with?

Bob

[TurboBob]

Replying to myself,  but I think I have improved the situation.

In expanding the HID demo to 64 byte reports, there appears to be *many* places in the code that need to be changed.  Many are "less than obvious".  My searching out and reading as much HID documents as possible, I did not locate a good reference for all of the elements of the descriptor configuration.

Watching things in True-Time,  I could not locate the buffers in the USB RAM, they seemed to be over-writing each other.  So I guessed that the buffers were not set up properly.

At any rate,  I located yet another element that needed to be changed to 64,  and now everything seems ok.

Testing is still incomplete,  but it seems much improved.

The line I needed to change is below:

Code:

  USB_FILL_EP_DESC(0x1, 1, 0x3, 64, 0x10),//                              ^-------------- this one was 8//                          even with this error, the USB seemed//                          to work "pretty well, most of the time"//                          The headers passed all of the tests//                          of the USB tools I could find.

 
I will post the results of the testing,  once it is complete.

Bob

[TurboBob]

Since the change to that one byte in the endpoint descriptor, the USB has worked properly 100%.  I have a few hours of testing completed.

Bob

[Goz]

Since I posted earlier today I seemend to have fixed it. It turned out that I hadn't declared one of my global variables as a static and was being corrupted while the code was calling other functions before it came to use it.

I am however getting a problem with loosing communications. The system is set up as a poll response type arrangement, with the PC sending a query and the USB device sending back a response. I don't know the timing between each poll, but it isn't very quick (100's of ms...although this is an assumption). 

It's being tested with existing application software that carries out the polls and I seem to be able to go round the loop between 5 to 10 times before it just stops. The USB device is still configured when it stops, but I have a feeling the application software on the PC gives up if it fails to get a response within a set time frame. I'l have to speak to the software guy who wrote the application to be 100% sure of the timings etc.

I'm not using processor expert, as I'm basically carrying out a modified port of an existing USB product to the demo kit, just to see if it is a viable route to market. Also running the latest version of CW.

I'm going to get some answers to my questions so that I don't carry on blidly into the unknown and may post back if I get really stuck.

Message Edited by Goz on 2009-01-27 02:43 PM

[TurboBob]

make sure your stack is large enough

[Goz]

Ok, the system is all working after a brief chat with the software guy. It's been up and running for an hour or so with no problems. Turns out the software is very picky about receiving a valid response that it wants to see.

Now comes another question. Does anyone know if the CMX lite stack is limited in the number of endpoints that can be used? To have more endpoints, you need more reports, but AN2492 states that 'the demo' (if this is the demo) is limited to a maximum of two reports....so have I answered my own question?

Now, out of curiosity I tried to add another endpoint, so I used endpoint 0 as a feature report, endpoint 1 as my OUT and endpoint 2 as my IN. I bumped up the MAX_NO_OF_REPORTS up to 3 (could be naughty?). I altered my config descriptor to state that the device used 2 endpoints and gave it a go. It seemed to configure ok but it seemed as if the stack was insisting that all Rx data was passed on to endpoint 0. I'm wondering if I have to modify the receive routines or if I am limited to just using endpoint 0 and endpoint 1.

If I am not limited, then how do I make sure that data being passed to the USB device receives it at the correct endpoint? am I missing something?

Thanks in advance.

[TurboBob]

A similar thing happend to me when I tried to define an additional endpoint.

Apparently I need  HID/USB for Dummies book to get me thru this stuff.

Bob

(thankfully,  the basics are working for me now,  luckily I am not trying to transfer huge amounts of data.)

[Goz]

Looks like I'm going to have some bedtime reading to do then

Thanks,

Goz