USB device stops responding

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ECamino on Thu Jul 18 12:13:25 MST 2013
Hi,

I have a composite device with two HIDs. One is a simple device, with one in ep, as HID2. The other device is a Vendor Defined HID interface with in/out endpoints. When sending data out to the VD device, it works for awhile and then suddenly it stops working. USBlyzer shows data is sent out from PC and no errors for status. Stepping through I can see that there is no longer any interrupting on HID_Ep_Hdlr on USB_EVT_OUT (don't know if USB_EVT_IN continues to work though).

The other device continues to work flawlessly on HID_EP_Hdlr2.

Once the device is initialized, there is no more interaction with the Hdlrs or any other USB configuration. What could cause one device not to work after awhile and another device continues to work?

Thanks,

EC

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ECamino on Wed Aug 21 11:38:42 MST 2013
Thanks, Tsuneo!

No, I looked at ES_LPC1315/16/17/45/46/47 and did not see anything about a silicon (ROM) issue having to do with the USB ROM Drivers.

I read the post from your link, and then I added this line right after the USB hw init:

[color=blue]

usb_param.mem_base = 0x10001000 + (0x1000 - usb_param.mem_size);

[/color]

I built it and it runs...hard to say if bug is gone as it's intermittent (yea!)

After I call the hid_init(), do I have to recalc the mem address and size again? If using a composite device, would that have to be done again after hid2_init()?

Per the second half of your linked post, I don't "reuse" any enpoints in the descriptors, so do I have to do the ep buffer size recalcs?

EC

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Tsuneo on Tue Aug 20 01:34:51 MST 2013
In this post, a bug on HW->init() of the ROM stack on LPC11Uxx was confirmed. HW->init() returns wrong mem_base and mem_size, which affect to allocation of following HID instances.
http://www.lpcware.com/content/forum/hw-init-and-hw-getmemsize-return-seemingly-incorrect-values

Did you apply the workaround in above post?

Tsuneo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ECamino on Thu Aug 15 11:32:26 MST 2013
Help, please? This one won't go away...

The problem is one HID device of a HID composite device stops responding when both devices and other peripherals of the LPC1347 are under "heavy" use. When the HID device stops working, the HID2 device and all other peripheral/program functions continue to work. It seems that the first device, HID, stops interrupting on the USB out.

We have a pc application that sends data to the first HID device and then the device replies. While debugging, I found that if I put breakpoints in the code at HID_Ep_Hdlr and/or at USB_IRQHandler, I can see data out and in before the program even breaks. It's like the USB API has already interrupted and run through call back functions before the program breaks at the first breakpoint at the IRQ. Could this be some kind of latency limitation of LPCXpresso?

I've tried looking for memory problems and have found nothing that would wipe the USB ram. If I look at the USB peripheral registers, nothing really seems to change. Are there certain reg values that could give me clues as to what happens with the HID device and interrupting?

Thanks,

EC

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ECamino on Fri Jul 26 13:13:59 MST 2013
The function pointer for HID_EP_Hdlr is not being wiped. We found that the interrupt stops working. Why would USB_IRQHandler() for only the one ep stop working? How to fix?

EC

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ECamino on Mon Jul 22 05:41:31 MST 2013

Quote: Tsuneo
Hi Camino,

Are you aware of my above post?
The post was trapped by forum censorship, for a couple of hours.
After salvaged by the webmaster, the post was put before your above post, along with the original post time. As the result, it wasn't entitled as a new post. It's hard to be aware of this "new" comment.

Frustrating forum engine.

Tsuneo

LOL...the forum isn't working too good today...I have to quote in order to get a "post" button on the comment page...I really just wanted to say this:

Hi Tsuneo,

Yes, I did see your post. If you look at the time stamps on my last post and your first post, it looks like we were online replying at the same time. We followed your instructions, got our function point address for HID_EP_Hdlr and today we're going to see if we have a memory issue like you suggested. Thanks for the help, it was very useful!

EC

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Tsuneo on Sat Jul 20 21:19:38 MST 2013
Hi Camino,

Are you aware of my above post?
The post was trapped by forum censorship, for a couple of hours.
After salvaged by the webmaster, the post was put before your above post, along with the original post time. As the result, it wasn't entitled as a new post. It's hard to be aware of this "new" comment.

Frustrating forum engine.

Tsuneo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ECamino on Fri Jul 19 06:54:56 MST 2013
I don't see any stalls. I can capture data and see that it there is a "Bulk or Interrupt Transfer Output Report len:255 out" Then the next line says 255 bytes buffer. The next transaction says the same thing except the second line says 0 bytes buffer. In between the PC program pings the device using control transfers on ep0.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Tsuneo on Fri Jul 19 06:51:42 MST 2013
Hi Camino,

By your former posts, I believe you are working on USB on-chip driver of LPC1347.

Quote:
USBlyzer shows data is sent out from PC and no errors for status.

It suggests, the USB engine works as expected, but HID_Ep_Hdlr is not called by the endpoint interrupt. Maybe, the HID instance (parameters) on the RAM are broken.

To confirm it,
After enumeration, put a break point here,

main.c

void USB_IRQHandler(void)
{
  pUsbApi->hw->ISR(hUsb);    // <-- put a break point, after enumeration
}

Send an output report to the device, and above break point should be hit.
Trace the ROM code from this break point, until HID_Ep_Hdlr() is called, by enabling "Instruction stepping mode" (i-> button).
http://support.code-red-tech.com/CodeRedWiki/DebugViewAsm

The function address of HID_Ep_Hdlr() is stored somewhere on the RAM, which is referred just before the ROM stack calls HID_Ep_Hdlr() indirectly. Mark the address of this function pointer. Is the value of this function pointer changed, when HID_Ep_Hdlr is no longer called?

Tsuneo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by stalisman on Fri Jul 19 00:11:46 MST 2013
You have a composite device which means they are independent and any host talks to them separately. The fact that one works and the other does not is fairly typical during development. It just means that one needs further debugging independent of the other device that is working.

Look to see if there is any indication of an endpoint being 'stalled'.