This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F5529: USB10 erratum

Part Number: MSP430F5529


Dear TI support team,

I am a HW architect with Siemens, and within my team we develop industrial HMI panels.

There is one device where we introduced the MSP430F5529 which acts as a USB touch controller for resistive touches.

Everything seemed to be fine, but now production has given us the feedback, that during final inspection about 0.2% of the panels fail to recognize the USB touch controller at first boot.

After a power cycle of the panel or even only a reset of the MSP430F5529, the USB touch controller will be detected by the host again.

We don’t know if some devices are more susceptible than others, but we sell about 30k/a, and the error occurs about 5 times a month.

My strong guess is that the error is related to the USB10 erratum. What do you think, is this feasible?

We now implemented the workaround as described in the errata description. We did some testing and could not find any issues. This said I can not commit that this workaround actually does fix the described error, although it didn’t occur so far during testing in the lab. But this is not the point of my question.

We are kind of hesitant, as the errata recommends implementing the workaround only in case it is definitely required, as it has the side effect of producing orphan tokens.

It is absolutely necessary that our devices are a 100% reliable. It is not acceptable that the touch is not operable in 0.2% of the boot cycles. But it would be even worse if the touch lost it’s operability after some days, weeks, … of operation. I say this, as usually our panels are operated 24/7 by our customers.

What is TI’s suggestion about thier workaround? Are you confident about your work around and therefore recommend introducing this new FW release in the field? As you understand, we need a fix which makes the TI uC reliable.

Thank you for your support.

Best regards,

Paul von Hase

  • Hi Paul

    Thanks for your mail and comment! Errata is the official document as the supplement of product DS. The description and workaround has been reviewed and tested as review and test on the production specification. Please confirm the Errata is the latest version: www.ti.com/.../slaz314ac.pdf

  • Hi Xiaodong,

    are you saying that you suggest implementing the workaround in our case? The Erratum is not a 100% clear.

    My guess is that implementing the USB10 workaround it is the right approach, as long as we won’t get malicious side effects by it, which will cause a malfunction with 24/7 operation after a longer operation time.

    Thanks,
    Paul

  • Hi Paul

    Thanks for you question! May I confirm if the Errata USB10 workaround has been implement on your solution or not?

    >> My strong guess is that the error is related to the USB10 erratum. What do you think, is this feasible?

    Could you please comment if the description of Errata USB10 is clear or not? is there any description need to be updated or need more clarification?

  • Hi Xiaodong,

    To be honest, I don't have the feeling that you are trying to support us with this issue.

    You keep on asking questions about things I have already described very much in detail. On the other side you don't answer any of my questions.

    The worst thing is that in your last post, although you exclusively put questions, you also ask if your post helped solving the issue.
    How should that happen? This is not apreciated :-(

    To answer your last questons again...

    The current situation is that we have a FW in the field, which does not include the USB10 erratum workaround. With this FW it occurs in 0.2% of all power up boots, that the MSP430F5529 will not be recognized by the USB host. Still we can see that the MSP430 is operational on other busses. Resetting the MSP will make it get visible by the USB host. This very much sounds like the USB10 bug of the MSP430. Do you agree?

    The reason that we didn't implement the USB10 erratum workaround till now is that your errata sheet warns about possible issues, in case the work around is implemented.

    So my basic question is if TI recommends to implement the USB10 work around in our case. Please consider that our panels are running 24/7 over weeks, months or even years. This said the workaround should not compromise long time stability. Is this the case?

    As I further wrote we now extended our current FW by implementing the USB10 work around, just as described in the erratum. It seems as if this extended FW works fine in your system test. Still we hesitate to introduce it, as the erratum states:

    "Although the workaround is field-tested, and no problems have been reported with these orphan packets, it is recommended to use the workaround only if the errata behavior is problematic for the application in question."

    To us the errata sheet states that this TI uC has a HW bug, and that Texas Instruments is not fully confident in their own work around.
    This is not a nice situation for your customers and the least we do expect is to get some support in deciding wheater or not the work around proposed by TI is worth the risk of getting problems because of its side effects.

    Thank you,
    Paul

  • Hello Paul,

    To add some clarity here, it does sound like you are affected by the USB10 erratum for this device in your application. Per the errata sheet, the simplest solution for your systems that are affected is to unplug then re-plug the device's USB connection. If that is not feasible for your system, then we recommend implementing the SW workaround described.  As a consequence of said SW workaround, orphan tokens/packets are created. Typically, these orphaned transactions result in no issues in USB communication if USB protocol is followed. (This is the underlying assumption in the wording of this erratum). However in practice, not all vendors or USB hosts/end-points follow the USB protocol to the letter for various reasons including erratum. Thusly, this workaround could possibly be an issue in systems that meet that kind of description. 

    It is not the intention of the wording of this particular erratum to convey confidence level of the workaround, but to allow for possible decision trees or explanations for why not to use the erratum in non-ideal situations or systems. Thank you for your feedback in the wording of this erratum. i will loop this back to the appropriate team so we can improve our documentation in the future. 

  • Hi Paul

    >> The worst thing is that in your last post, although you exclusively put questions, you also ask if your post helped solving the issue.
    How should that happen? This is not apreciated :-(

    "If my post helped solve your issue, please click on the  VERIFY ANSWER  button" is one part of my signature.because you feel it is not apreciated, I have removed the word in my signature

    >> So my basic question is if TI recommends to implement the USB10 work around in our case.

    I have replied "Errata is the official document as the supplement of product DS". if your system issue is the same or similar with the description of the Errata, Workaround should be implemented.

    My colleague Jace H has replied your question as well, we are discussing your question these days. I think his comment is more professional.

  • Hello Jace,

    Your answer gives us some more confidence and understanding of the risks.

    It is helpful that you also think that the problem we occure is related to the USB10 bug. We obviously wouldn't want to add a risk with the workaround in case it was not necessery.

    After having tested the new FW with the USB10 workaround in the lab, and having gotten your answer, we will now start some even more intense testing in the system test department.

    I am confident that we will pass this test and therefore will be able to introduce the new FW in the field.

    Thank you.

    Regards,
    Paul

**Attention** This is a public forum