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.

MSP430F5510: USB12 Errata

Part Number: MSP430F5510

Hi All,

Please tell us about USB Errata USB 12 of MSP430F5510.

There is "The 2nd byte of a slave-to-host transmission is sent twice." What Timing will this 2byte be sent to?

Is it transmitted only once when the USB Bus becomes undetermined state? Or will it be sent several times?

Workaround says "If automatic detection of the error is required, then software on the host and device can CRC check on the data payload (above the USB API) to detect the extra byte."

Is there a Sample Program on this CRC check?

Best Regards,

Takashi

  • Hi Takashi,

    The 2nd byte will be transmitted at the same timing as the rest of the bytes in the USB communication. I believe this extra byte will be sent each time a slave-to-host transaction occurs, which is why the USB module needs t be reset and reinitialized when this undetermined state occurs.

    As for the CRC check, any CRC algorithm can be used, as long as the software on both the host and device sides use the same CRC implementation. This is simply to check if the bytes that are sent to the host are the same as the ones that were supposed to be sent (an extra byte will result in the received data producing a different CRC).

    Regards,
    Nathan
  • Hi Nathan-san,

    Thank you for your reply.
    I contacted the customer and added Disable / Enable of USBEN bit of Workaround to the main routine.
    As a result, I was informed that it was recognized by Device Manager but USB communication was not done.

    By USB Transaction, I'm informed that originally 8 byte of communication, there was 9 byte transmission.
    (It has not been confirmed whether 2nd byte has been sent twice.)

    As mentioned above, is it recognized by the device manager, but there is anything that the USB communication can not be done?

    Best Regards,
    Takashi
  • Hi Takashi-san,

    To clarify, was the USB port not recognized in Device Manager before adding the USBEN workaround? If you are still seeing an extra byte sent, then it is probably something other than USB12. Either way, this can only be known if you can figure out what the extra byte that was sent was.

    Regards,
    Nathan
  • Hi Nathan-san,

    I reconfirmed to customers.

    In order to reproduce the contents of USB12 Errata, processing to turn ON / OFF USBPLLEN bit is added.

    Then, they connect the hardware to the PC and carry out the PC's reboot test.

    (USBEN bit ON / OFF is not added. And because the USB Bus Power is ON, the MSP430's power is not OFF.)

    Normally, 8-byte communication is performed after enumeration, but rarely 9 byte transmission is sometimes done.

    After that, although it is recognized by the device manager, USB communication can not be performed.

    Reboot the PC after this state has been reached, repeat communication, 9 byte transmission will be done.

    Although all contents of 8byte data are not known, the leading 2bytes are transmitting "0x00". (ex:0x00, 0x00, 0x12, 0x34, 0x56, 0x78, 0x9a, 0xbc)

    The data when transmitting 9 bytes, the first 3 bytes is "0x00".

    I do not know either 1st byte or 2nd byte, but I believe that either "0x00" was repeatedly transmitted.

    Is the above state Errata USB12?

    Also, please let me know in addition.

    In the description of Errata USB 12, it says "The PLL is normally disabled by software when USB device has been the suspended by the host.

    What is the purpose of disabling the PLL? Is it due to low power consumption?

    Best Regards,

    Takashi

  • Hi Takashi-san,

    All I can say based on the information that you provided is that it is consistent with USB12. Could the customer make the first 2 bytes different values to check for sure if it is the second byte that is being resent? This would help confirm that it is the behavior of the errata.

    As for the PLL, I suspect it is just good practice because it is not being used during that time. This will save power and prevent any possible issues from arising involving the PLL.

    Regards,
    Nathan

**Attention** This is a public forum