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.

MSP430FG6626: Bug in MSP430 USB DEV PACKAGE. Alternate msg timeout using HID datapipe

Part Number: MSP430FG6626
Other Parts Discussed in Thread: MSP430F5510,

Hi Folks.

I have issues with the MSP430 USB DEV Package. I'm working with the download 5.20.071 (but confusingly, the downloaded zip contains 5.20.06)

www.ti.com/.../5.20.07.01

I'm using the HID datapipe, with the standard VID, and a PID supplied by TI.

The issue causes every other message to timeout.  I didn't notice for some time because my PC was retrying. 

Once I noticed, I checked with Wireshark and saw good HID packets being sent each time.

I traced the problem to the function "USBHID_getBytesInUSBBuffer" in USBHid.c

 

Below is the original function

/*
* Returns how many bytes are in the buffer are received and ready to be read.
*/
uint8_t USBHID_getBytesInUSBBuffer (uint8_t intfNum)
{
uint8_t bTmp1 = 0;
uint8_t bTmp2;
uint8_t edbIndex;
uint16_t state;
edbIndex = stUsbHandle[intfNum].edb_Index;
//interrupts disable
state = usbDisableOutEndpointInterrupt(edbIndex);
if ((bFunctionSuspended) || (bEnumerationStatus != ENUMERATION_COMPLETE))
{
//if suspended or not enumerated - report 0 bytes available
usbRestoreOutEndpointInterrupt(state);
return (0);
}
if (HidReadCtrl[INTFNUM_OFFSET(intfNum)].nBytesInEp > 0)
{
//If a RX operation is underway, part of data may
//was read of the OEP buffer
bTmp1 = HidReadCtrl[INTFNUM_OFFSET(intfNum)].nBytesInEp;
if (*HidReadCtrl[INTFNUM_OFFSET(intfNum)].pCT2 & EPBCNT_NAK)
{
//the next buffer has a valid data packet
//holds how many valid bytes in the EP buffer
bTmp2 = *(HidReadCtrl[INTFNUM_OFFSET(intfNum)].pEP2 + 1);
if (bTmp2 > (*HidReadCtrl[INTFNUM_OFFSET(intfNum)].pCT2 & 0x7F) - 2)
{
//check if all data received correctly
bTmp1 += (*HidReadCtrl[INTFNUM_OFFSET(intfNum)].pCT2 & 0x7F) - 2;
}
else
{
bTmp1 += bTmp2;
}
}
}
else
{
if (tOutputEndPointDescriptorBlock[edbIndex].bEPBCTX & EPBCNT_NAK)
{
//this buffer has a valid data packet
bTmp2 = tOutputEndPointDescriptorBlock[edbIndex].bEPBCTX & 0x7F;
bTmp1 = *((uint8_t*)stUsbHandle[intfNum].oep_X_Buffer + 1);
if (bTmp2 - 2 < bTmp1)
{
//check if the count (second byte) is valid
bTmp1 = bTmp2 - 2;
}
}
if (tOutputEndPointDescriptorBlock[edbIndex].bEPBCTY & EPBCNT_NAK)
{
//this buffer has a valid data packet
bTmp2 = tOutputEndPointDescriptorBlock[edbIndex].bEPBCTY & 0x7F;
if (bTmp2 - 2 > *((uint8_t*)stUsbHandle[intfNum].oep_Y_Buffer + 1))
{
//check if the count (second byte) is valid
bTmp1 += *((uint8_t*)stUsbHandle[intfNum].oep_Y_Buffer + 1);
}
else
{
bTmp1 += bTmp2 - 2;
}
}
}
// Restore interrupt
usbRestoreOutEndpointInterrupt(state);
return (bTmp1);
}

This is the modified function below. 

I'm no expert in USB, this is working for me.

 

//----------------------------------------------------------------------------
/* Returns how many bytes are in the buffer are received and ready to be read. */
BYTE USBHID_bytesInUSBBuffer(BYTE intfNum)
{
BYTE bTmp1 = 0;
BYTE bTmp2;
BYTE bTmp3;
BYTE edbIndex;
WORD state;

edbIndex = stUsbHandle[intfNum].edb_Index;
//interrupts disable
state = usbDisableOutEndpointInterrupt(edbIndex);
if ((bFunctionSuspended) || (bEnumerationStatus != ENUMERATION_COMPLETE))
{
//if suspended or not enumerated - report 0 bytes available
usbRestoreOutEndpointInterrupt(state);
return (0);
}
if (HidReadCtrl[INTFNUM_OFFSET(intfNum)].nBytesInEp > 0)
{
//If a RX operation is underway, part of data may
//was read of the OEP buffer
bTmp1 = HidReadCtrl[INTFNUM_OFFSET(intfNum)].nBytesInEp;
if (*HidReadCtrl[INTFNUM_OFFSET(intfNum)].pCT2 & EPBCNT_NAK)
{
//the next buffer has a valid data packet
//holds how many valid bytes in the EP buffer
bTmp2 = *(HidReadCtrl[INTFNUM_OFFSET(intfNum)].pEP2 + 1);
if (bTmp2 > (*HidReadCtrl[INTFNUM_OFFSET(intfNum)].pCT2 & 0x7F) - 2)
{
//check if all data received correctly
bTmp1 += (*HidReadCtrl[INTFNUM_OFFSET(intfNum)].pCT2 & 0x7F) - 2;
}
else
{
bTmp1 += bTmp2;
}
}
}
else
{
if (tOutputEndPointDescriptorBlock[edbIndex].bEPBCTX & EPBCNT_NAK)
{
//this buffer has a valid data packet
bTmp2 = tOutputEndPointDescriptorBlock[edbIndex].bEPBCTX & 0x7F;
bTmp1 = *((BYTE *)stUsbHandle[intfNum].oep_X_Buffer + 1);
if (bTmp2 - 2 < bTmp1)
{
//check if the count (second byte) is valid
bTmp1 = bTmp2 - 2;
}
}
if (tOutputEndPointDescriptorBlock[edbIndex].bEPBCTY & EPBCNT_NAK)
{
//this buffer has a valid data packet
bTmp2 = tOutputEndPointDescriptorBlock[edbIndex].bEPBCTY & 0x7F;
bTmp3 = *((BYTE *)stUsbHandle[intfNum].oep_Y_Buffer + 1);
if (bTmp2 - 2 < bTmp3)
{
//check if the count (second byte) is valid
bTmp1 = bTmp3 - 2;
}
else
{
bTmp1 = bTmp3;
}
}
}
// Restore interrupt
usbRestoreOutEndpointInterrupt(state);
return (bTmp1);
}
  • Hi,

    Could you try rearming the USBHID_receiveData() after receiving?

  • Hi.

    The USB code was originally used on another project using the MSP430F5510. The MSP430F5510 was not affected by the issue.

    Function "hidReceiveDataInBuffer" already has an additional USBHID_receiveData call inserted, as per a previous TI bug fix, and just adding another receivedData isn't that just masking the issue?

    Below is a debug printout of the functions called in my firmware when a HID packet is received. This is produced by fixed code, as shown above. This is how I tracked down the issue to "USBHID_bytesInUSBBuffer".

    //This is a good received HID packet, and it is successfull 100% of the time.

    HidIsReceiveInProgress [UserBuf == NULL]
    iUsbInterruptHandler [no HidIsReceiveInProgress]
    iUsbInterruptHandler [dataReceivedEvent]
    hidReceiveDataInBuffer [add = 2c94] [size= 64]
    USBHID_bytesInUSBBuffer
    USBHID_bytesInUSBBuffer [nBytesInEp = 0] [A] [B] [C] [D]
    USBHID_bytesInUSBBuffer [bytes = 62]
    USBHID_receiveData [size = 62]
    HidCopyUsbToBuff [bytes = 62]
    HidCopyUsbToBuff [inEp = 62]
    USBHID_bytesInUSBBuffer
    USBHID_bytesInUSBBuffer [nBytesInEp = 0] [A] [D]
    USBHID_bytesInUSBBuffer [bytes = 0]
    ok


    //This is my debug of the original code; only the 1st and 3rd packets are received correctly, and it continues in this alternating good/bad packet sequence. The error responses can vary. 


    HidIsReceiveInProgress [UserBuf == NULL]
    iUsbInterruptHandler [no HidIsReceiveInProgress]
    iUsbInterruptHandler [dataReceivedEvent]
    hidReceiveDataInBuffer [add = 2c94] [size= 64]
    USBHID_bytesInUSBBuffer
    USBHID_bytesInUSBBuffer [nBytesInEp = 0] [A] [B] [C] [D]
    USBHID_bytesInUSBBuffer [bytes = 62]
    USBHID_receiveData [size = 62]
    HidCopyUsbToBuff [bytes = 62]
    HidCopyUsbToBuff [inEp = 62]
    USBHID_bytesInUSBBuffer
    USBHID_bytesInUSBBuffer [nBytesInEp = 0] [A] [D]
    USBHID_bytesInUSBBuffer [bytes = 0]
    ok


    HidIsReceiveInProgress [UserBuf == NULL]
    iUsbInterruptHandler [no HidIsReceiveInProgress]
    iUsbInterruptHandler [dataReceivedEvent]
    hidReceiveDataInBuffer [add = 2c94] [size= 64]
    USBHID_bytesInUSBBuffer
    USBHID_bytesInUSBBuffer [nBytesInEp = 0] [A] [D] [E]
    USBHID_bytesInUSBBuffer [bytes = 0]
    RX-Err


    HidIsReceiveInProgress [UserBuf == NULL]
    iUsbInterruptHandler [no HidIsReceiveInProgress]
    iUsbInterruptHandler [dataReceivedEvent]
    hidReceiveDataInBuffer [add = 2c94] [size= 64]
    USBHID_bytesInUSBBuffer
    USBHID_bytesInUSBBuffer [nBytesInEp = 0] [A] [B] [C] [D] [E]
    USBHID_bytesInUSBBuffer [bytes = 62]
    USBHID_receiveData [size = 62]
    HidCopyUsbToBuff [bytes = 62]
    HidCopyUsbToBuff [inEp = 62]
    USBHID_bytesInUSBBuffer
    USBHID_bytesInUSBBuffer [nBytesInEp = 0] [A] [B] [C] [D]
    USBHID_bytesInUSBBuffer [bytes = 62]
    USBHID_receiveData [size = 2]
    HidCopyUsbToBuff [bytes = 2]
    HidCopyUsbToBuff [inEp = 62]
    ok


    HidIsReceiveInProgress [UserBuf == NULL]
    iUsbInterruptHandler [no HidIsReceiveInProgress]
    iUsbInterruptHandler [dataReceivedEvent]
    hidReceiveDataInBuffer [add = 2c94] [size= 64]
    USBHID_bytesInUSBBuffer
    USBHID_bytesInUSBBuffer [nBytesInEp = 60]
    USBHID_bytesInUSBBuffer [bytes = 60]
    USBHID_receiveData [size = 60]
    HidCopyUsbToBuff [bytes = 60]
    HidCopyUsbToBuff [inEp = 60]
    USBHID_bytesInUSBBuffer
    USBHID_bytesInUSBBuffer [nBytesInEp = 0] [A] [D] [E]
    USBHID_bytesInUSBBuffer [bytes = 0]
    RX-Err

  • Hi,

    Let me take a look. I will get back to you once I find an expert on this subject. 

    -Matthew

  • Any update Matthew?  It's been 6 days. 

  • Hi Nick,

    Sorry for the delay!

    I *think* you're experiencing a situation where there's an issue with the packet size logic which it seems you resolved with your fix.

    1) Could you elaborate on what your setup is and what data you are sending?

    2) Does this happen on other devices of the same part number?

    It is not clear what your question is. It sounds like your edit fixed your issue and that you are asking us to investigate why the library code seems to be broken on this device?

  • We send the full datapipe size each time, 62 bytes. I have 2 product types. The older product used the MSP430F5510 and has no issue; only the MSP430FG6626 has this issue. It happens on all MSP430FG6626 without fail.  Currently, all my MSP430FG6626s are REV A.

    If you send me your email, I will send you my source code. The problem you might have with my source code is that it was compiled with Rowley CrossStudio for MSP430. But the differences are very minor. All my products use Rowley CrossStudio.

    I know my edit fixed the problem on my device, but because I'm not an expert, I wanted to check that I didn't do something that will bite me later. I don't expect a detailed investigation; just a nod that it's okay or that I should do something else. Remember this is TI code, not my project code.

    I guess you want to continue supporting MSP430FG6626, and other customers might have the same problem? again TI code, not mine.

    You didn't answer the question about the USB DEV package, and why download 5.20.071 zip contains the 5.20.06  (initial post).

  • Hi,

    I have reached out to the TI sales rep. Let's take this to email. It will require deeper conversation to come to a definitive answer.

    -Matthew

  • Hi Nick,

    It looks okay from our side, but definitely let us know if any issues arise later. These types of questions can be application specific.

    However, nothing stands out as a red flag to us.

    As for the version number difference....it's likely because the zip file contains multiple sub folders that have their own versioning, so it's not always aligned. However, I can't speak for the developers who worked on it almost 10 years ago.

    -Matthew

**Attention** This is a public forum