Is there a reference manual available for the SIE used on the K20?

[dsaathoff]

We are using the Freescale Version 4.1.1 USB stack.  When an unsupported HID command is received for one of the interfaces, the stack processes the required STALL response.  However, when the response is ready and waiting for the next IN PID to respond to, it gets a SETUP PID instead.  This results in EP0 shutting down. 

[bobpaddock]

The Microchip documentation on the SEI is clear than the Freescale/NXP documentation:

http://ww1.microchip.com/downloads/en/DeviceDoc/61126F.pdf 

The register names are different, the functionality is the same.

All these parts are decedents of some purchased third-party USB IP core.

I agree with Mark it is a code issue. 

The USB spec says that when SETUP comes in (which could be host issues many of those don't read the USB spec sadly) the Device must be ready to abandon any transaction in progress and handle the SETUP.

Also Windows will reset the device at least twice once to read the descriptor length, once to read the descriptor.

Perhaps this is the reason for seeing more than expected?  Doesn't really sound like it from your IN question.

Stalls, for those items required by enumeration,  and Timeouts are never allowed during enumeration.

An IN Endpoint must be primed and ready to reply with data or ready to NAK if no data BEFORE enumeration completes.

The Gurus of USB hang out here: USB at Jan Axelson's site.  I highly recommended her book USB Complete, fifth edition or later.

[mjbcswitzerland]

Hi

The SIE description is found in the K20 user's manual in the USB-OTG section.

If the endpoint stalls the host will send a clear feature request in order to clear it (unstall), which is probably what you are seeing. The stalled state is cleared by resetting the STALL flag in the corresponding IN endpoint's control register, or the STALL flags in the buffer descriptors (both odd and even!) of OUT endpoints.

Regards

Mark

[dsaathoff]

Mark,

Thanks for the quick reply. We've been trying to get answers to this question for a few months now but to no avail.

Below is an example of what we are seeing. Both traces are from the same communication between the host/hub and our keyboard.

In this first trace, we are sending a SET_IDLE to Interface 1 which is not supported (it's only supported on Interface 0). As you can see, the STALL response is what you would expect.

However, just a short time later we try sending the SET_IDLE to Interface 1 again. This time, we receive a SETUP with a SET_IDLE instead of the expected IN token. As you can see, all hell then breaks loose.

We are using the Freescale Version 4.1.1 USB stack basically unmodified.

Do you have an explanation for this?

Thanks for your help,

Kind Regards,

David Saathoff

Sr. Project Engineer

Cherry Americas, LLC

11200 88th Avenue

Pleasant Prairie, WI 53158 / USA

Phone +1 262-942-6397

Mobile +1 262-308-3034

david.saathoff@zf.com<mailto:david.saathoff@zf.com>

www.cherryamericas.com<http://www.cherryamericas.com>;

<http://www.cherrycorp.com/>

This message is a PRIVATE communication. If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you for your help.

[mjbcswitzerland]

David

At the first glance this looks to be a host issue - are you using both host and device modes in the stack?

Regards

Mark

[dsaathoff]

This is a keyboard used on our customer's system. When we pushed back as you note below, they pointed out that per the USB specification, a STALL on EP0 should be cleared on receipt of the next SETUP PID.

[mjbcswitzerland]

David

OK - I now understand that you "are" the keyboard device that is returning a stall when the host sends the SET_IDLE to its interface 1.

I don't know why the host is repeating the same SET_IDLE (which I would expect to be simply stalled again) but I understand that the basic issue is that this 'following' transaction from the host is showing the problem (and not which transaction it actually is).

I have also attached a recording of a typical HID case which does this. In this case the following transaction is not a repeat of the SET_IDLE but a GET DESCRIPTOR (also a SETUP transaction) so it should be equivalent. It just shows that this is normal activity and the following transaction continues normally.

In your recording I see that there are "ERROR" blocks shown in the host's transmission which led me to initially think that it may be a host problem (and you were using a host interface in your project) but after a bit of reflection (I don't know the analyser view) I now am assuming that it is not actually signalling that the host transmission was bad but instead that the host transmission was probably never acked by the device (I can't see any other thing that it could be representing because the data content looks OK). I also see that the SETUP is in fact repeated a number of times, which the host controller (very low level) will do when there is a transmission problem - like a CRC error causing the device to not ack.

Therefore my conclusion would now be that the USB device is sort or disabled (dead) at this point, which would be more serious than the software crashing etc. since malfunctioning SW wouldn't stop the controller itself from at least responding to a SETUP with an ACK, since this takes place in the HW. My presumption is therefore that the stall has deactivated endpoint 0 (or blocking its ping-pong buffers for further reception), in which case you will need to investigate the handling of the stall transmission to find out why it has done this and correct it accordingly.

As reference, a stall is performed simply by setting the STALL flag in the endpoint's buffer descriptors (both). At the same time the buffer descriptors need to be freed (the OWN bit set).

                    ptEndpointBD->usb_bd_tx_even.ulUSB_BDControl = (OWN | BDT_STALL);
                    ptEndpointBD->usb_bd_tx_odd.ulUSB_BDControl  = (OWN | BDT_STALL);

check that the OWN bit is not being forgotten....

I can't comment of the 4.1.1 USB stack since I never really used it - it was very complicated to understand due to its many registered callbacks that made it almost impossible to follow. Probably the advice will be to move to the V5.0 stack but I also don't know what is better and what new problems it may bring?

If you can't find it and need a solution I can offer a resolution [debugging/identification/correction] (based on 8 years of intensive USB development experience) or could offer the uTasker USB stack which has been industrially proven in many intensive products and of course includes USB keyboard support (that can be mixted with a number of other composite classes with no effort). It also allows Kinetis USB controller simulation and complete project simulation to aid in general development efficiency and product quality.

Regards

Mark

[dsaathoff]

Mark,

The OWN bit is being handled correctly in the firmware. It seems like it's something embedded in the SIE itself; it's expecting the IN token to ACK with the STALL and getting the SETUP instead sends it off someplace else. That is why I originally asked for information on the SIE itself. It must be doing something out of the ordinary at that point and we need to add code to handle it.

I appreciate your comment about the 4.1.1 stack; I thought it was just me that was confused by it. At this point, switching to another stack may not be an option, though.

Dave

[mjbcswitzerland]

Dave

I have used many Kinetis parts (also Coldfires, which essentially have the same USB OTG controller) in a variety of products where stalls take place as part of normal operation so am convinced that what you are seeing must be due to coding errors. (I don't know whether more detailed SIE information will be that useful).

- Fixing such a bug in your stack should be possible with a couple of hours of work.

- If you have a bare-metal project, moving it to the uTasker environment (and inheriting USB device reliability) should be possible in about a day.

Regards

Mark

[dsaathoff]

The coding for a stall condition is the same for when the SIE responds correctly with a STALL and when it does not. The only difference is that in the first case, an IN token is received from the host/hub but in the second a SETUP token is received. It's hard to imagine a coding error would work in one situation and not the other when the token processing is handled by the SIE and not visible to the MCU. All the code has to work with are the interrupts received back from the SIE; the BD is loaded the same in both cases. We don't see how that would prevent the SIE from generating an interrupt on receipt of the SETUP token.

[mjbcswitzerland]

Dave

>>We don't see how that would prevent the SIE from generating an interrupt on receipt of the SETUP token

I believe there is no interrupt because the SIE doesn't return an ACK, which means that the SIE never saw the SETUP. The only explanation that I have for it not returning an ACK is that it is not in an operational state at that time. I say that there must (in the sense of a very high probability) be a coding error to cause this because somewhere it must have been (unintentionally (?)) 'switched' to this non-operating state.

If you are sure that it is not a problem with the chip that you are using or the HW, your will either need to debug the code and fix it or move to a different code. If you have any doubts about the chip/HW it may be beneficial to test the same operation on an evaluation board or two, possibly with different Kinetis parts to confirm always identical behavior.

Regards

Mark