FSL_USB_Stack updated: sending 16 or 32 byte blocks

Posted on by

The FSL_USB_Stack Embedded Component presented in “USB CDC, reloaded” has been updated to V1.004 and is available here. I was running into issues if the USB CDC stack had to send out either 16 or 32 bytes of data in the App_Task() function. In that case the data is not sent until the next USB_Class_CDC_Interface_DIC_Send_Data() request.

The code in the #if 1 ... #endif block below (line 27) fixed the problem:

byte %'ModuleName'%.%App_Task(byte *txBuf, size_t txBufSize)
{
  uint8_t i;

  %if (CPUDevice="MC9S08JE128") | (CPUDevice="MC9S08JM16") | CPUDevice="MC9S08JM60") | (CPUDevice="MC9S08JS16") | (CPUDevice="MC9S08MM128")
  if(USB_PROCESS_PENDING()) {
    USB_Engine();
  }
  %endif
  /* call the periodic task function */
  USB_Class_CDC_Periodic_Task();
  /* check whether enumeration is complete or not */
  if ((start_app==TRUE) && (start_transactions==TRUE)) {
    if (inherited.TxBuffer.NofElements()!=0) {
      i = 0;
      while(ii])==ERR_OK) {
        i++;
      }
      if (USB_Class_CDC_Interface_DIC_Send_Data(CONTROLLER_ID, txBuf, i)!=USB_OK) {
        /* Send Data Error Handling Code goes here */
        %if defined(OnError)
        %OnError(%'ModuleName'%.USB_ERR_SEND);
        %endif
        return ERR_FAULT;
      }
      #if 1 /* workaround for strange problem in USB stack v3.1.1: a 16 or 32 byte block is not sent? */
      if (i==32 || i==16) {
        /* workaround: sending a dummy block of zero bytes */
        USB_Class_CDC_Interface_DIC_Send_Data(CONTROLLER_ID, txBuf, 0);
      }
      #endif
    } /* if */
    return ERR_OK;
  } else {
    %if defined(OnError)
    %OnError(%'ModuleName'%.USB_ERR_BUSOFF);
    %endif
    return ERR_BUSOFF; /* USB bus not available yet */
  }
}

Happy CDCing 🙂

6 thoughts on “FSL_USB_Stack updated: sending 16 or 32 byte blocks”

  2. Hi,

    I am trying to use openocd to debug Kinetis K60. This board has MC9S08JM60 JTAG device. Can you please point me to docs where I can find details of setting up openocd to debug ?

    Thanks,
    Subbarao

    Like

    Reply ↓

  3. Apparently Freescale “fixed” this in version 4.0 of their USB stack such that I have a problem only when the # of bytes does NOT equal 16! Specifically, I’m making several calls to USB_Class_CDC_Interface_DIC_Send_Data in succession and trying to synchronize with the stack by either (1) waiting for the USB_APP_SEND_COMPLETE event in USB_App_Callback, or (2) waiting for a USB_OK from the call to the Send_Data routine itself. Either way results in the same data loss as it seems the flag is not always correct if the buffer size does not = 16. It works just fine, however, if each data buffer length is 16.

    I believe you mentioned in a post on Freescale that you had found a way to correct the overrun issue, but I could not find any details about that. Were you successful and, if so, I’d sure appreciate knowing what you did. Thank you very much!

    Like

    Reply ↓

    • Hi Phil,
      interesting, I need to check this out once I find a little time to breath. I know I tried to remove my workaround for 4.0.3 stack, but it did not work out well, so I decided to put it back in place. That’s probably what you see too.

      Like

      Reply ↓

      • Erich,

        Thanks for your quick reply. It’s helpful to know you’re having the same kind of problem. I’m planning to dig into the driver code today and would certainly appreciate any suggestions as to where you think the problem lies and what steps you took to bypass it.

        But please do catch a few breaths first. We wouldn’t want you to become “doxygen-ated!”

        Like

        Reply ↓

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.