• AVR Freaks

USB Firmware Framework Confirmed and Potential Anomalies

Page: 12345.. > >> Showing page 1 of 7
Author
xiaofan
Super Member
  • Total Posts : 6247
  • Reward points : 0
  • Joined: 2005/04/14 07:05:25
  • Location: Singapore
  • Status: offline
2007/08/15 05:02:31 (permalink)
0

USB Firmware Framework Confirmed and Potential Anomalies

Note on 20-Jan-2010: for a summary, please refer to Post 91.
http://www.microchip.com/forums/fb.aspx?m=468985

I want to compile a list of confirmed and unconfirmed anomalies for the Microchip USB Firmware Framework.

This is the placeholder for future updates.
post edited by xiaofan - 2010/02/09 18:14:09
#1

123 Replies Related Threads

    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 05:11:04 (permalink)
    0
    1. Firmware errata related to ambiguous definitions in usbdrv.h (version 1.0 date 11/09/04)
    http://ww1.microchip.com/downloads/en/AppNotes/USB%20Firmware%20Library%20Errata.pdf

    2. PKTDIS bug in USBCtrlEPServiceComplete
    Detailed discussion:
    http://forum.microchip.com/tm.aspx?m=78666


    "Microchip has just added an errata item to the PIC18F2455/2550/4455/4550 Rev. A3 Silicon Errata that seems to address this thread:

    10. Module: USB
    When an IN endpoint is owned by USB SIE and the UCON register PKTDIS bit is set, if a USB NAK event occurs on the IN endpoint before the PKTDIS bit is clear, then after the PKTDIS is clear, the pending IN endpoint will send out more bytes than expected. For example, if configured to send out 8 bytes, the SIE would actually send out 12 bytes of data.

    Work around
    The PKTDIS bit is set when a USB control transfer setup packet is received. Clear this bit as soon as possible, and clear it before turning over any IN endpoint ownership to the SIE. In the distributed C18 version of the USB library, the following change should be made:

    File: usbctrltrf.c, version 1.0, dated 11/19/04
    Function: void USBCtrlEPServiceComplete(void)
    Required Modification: Move UCONbits.PKTDIS = 0, which is located at the end of the function, to the start of the function instead."


    3. Ping-Pong Buffer Mode 3 does not work
    A3 silicon Errata:
    http://ww1.microchip.com/downloads/en/DeviceDoc/80220g.pdf

    14. Module: USB
    The Ping-Pong Buffer mode in which the ping-pong buffers are enabled for Endpoints 1 to 15
    (UCFG<PPB1:PPB0> = 11) is not supported.
    Work around
    Use other Ping-Pong Buffer modes.
    Date Codes that pertain to this issue:
    All engineering and production devices.


    Microchip may have solved the problem with later silicon. The following B4/B5 errata do not mention this bug any more.
    http://ww1.microchip.com/downloads/en/DeviceDoc/80287c.pdf
    http://ww1.microchip.com/downloads/en/DeviceDoc/80322a.pdf

    Other references:
    Ping-pong buffer related threads in the forum:

    Need USB ping pong buffer example
    http://forum.microchip.com/tm.aspx?m=147075

    Ping Pong with Brad Minch's firmware
    http://forum.microchip.com/tm.aspx?m=273995

    USB Ping Pong Buffering with the PIC18F4550 (very good explanation from Pacer)
    http://forum.microchip.com/tm.aspx?m=88264

    Misc threads:
    http://forum.microchip.com/tm.aspx?m=190828
    http://forum.microchip.com/tm.aspx?m=111182
    http://forum.microchip.com/tm.aspx?m=165751
    post edited by xiaofan - 2010/02/08 22:01:00
    #2
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 05:34:24 (permalink)
    0
    4. ACTVIF bug in usbdrv.c (USBWakeFromSuspend)
     
    First discussion by Pacer:
    http://forum.microchip.com/tm.aspx?m=89669

    Looking at your code, fairly briefly I must admit, one thing which struck me was that compared to microchip's code for the 18F4550, you don't seem to be masking off events which are not approriate at the current state. For example they tend to use the IDLEIE bit as an aid memoire to whether it is apropriate to handle IDLEIF. And similarly with ACTVIE and ACTVIF. They make some sort of comment about the logic of this. This is one of my two issues with this chip. It is not clear exactly how the logic which sets these two flags actually works. When I wrote a suspend routine based on their C code, I found that I was not recovering correctly from the first suspend, and was missing resets as a result. In the end I resorted to moving the clearing of IDLEIF till after an ACTVIF had been detected.

     
    I think there are some other discussions on this but I just could not find it right now.
     
    One potential fix:
     

    void USBWakeFromSuspend(void)
    {
        /*
         * If using clock switching, this is the place to restore the
         * original clock frequency.
         */
        UCONbits.SUSPND = 0;
        UIEbits.ACTVIE = 0;
        UIRbits.ACTVIF = 0;
    }//end USBWakeFromSuspend

     
    Should be:
     

    void USBWakeFromSuspend(void)
    {
        /*
         * If using clock switching, this is the place to restore the
         * original clock frequency.
         */
        UCONbits.SUSPND = 0;
        UIEbits.ACTVIE = 0;
        // UIRbits.ACTVIF = 0;                          
        while(UIRbits.ACTVIF){UIRbits.ACTVIF = 0;}      
       
    }//end USBWakeFromSuspend

     
    Also one should be careful about the suspend code (the modifiable section). To comment them out is the easier way to do but may not be proper way depending on the circuit. One should be careful about the current consumption.
    #3
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 05:40:55 (permalink)
    0
    5. USB error handler bug in usbdrv.c
    Leo Bodnar found this bug here:
    http://forum.microchip.com/tm.aspx?m=138656
    Some further explanation here:
    http://forum.microchip.com/tm.aspx?m=254471


    void USBErrorHandler(void)
    {
      UIRbits.UERRIF = 0;
    }//end USBErrorHandler
     

    This should be changed to:


    void USBErrorHandler(void)
    {
      UEIR = 0;                       // Clear all USB error flags, automatically resets UERRIF
    }//end USBErrorHandler
    post edited by xiaofan - 2007/08/15 05:42:16
    #4
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 05:56:37 (permalink)
    0
    6. Microchip Generic USB driver may not work with Vista
    http://forum.microchip.com/tm.aspx?m=241830
     
    Potential fix: WinUSB (no isochronous transfer support, Vista and XP only), libusb-win32, cypress ezusb or cyusb driver, Windows DDK bulkusb and isousb driver, roll your own driver, ...
    #5
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 06:10:05 (permalink)
    0
    7. Potential Anomalies in the STALL handler and ClearFeature report handler
    Report 1: PICkit 2, libusb and FreeBSD USB stack problem and fix
    http://forum.microchip.com/tm.aspx?m=243771
    report 2: Stalled Bulk_in endpoint EP3_IN in USB CDC device
    http://forum.microchip.com/tm.aspx?m=261192
     
    Potential fix <not sure here>:
    1) Rewrite the STALL handler for EP0 (protocol stall)
    2) Add handler for other endpoints (that will depending on the endpoints used)
    2) Rewrite the clear HALT feature report handler (only change the data toggle)
     
    #6
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 06:25:35 (permalink)
    0
    8. CDC-ACM implementation potential problems from Travis Robinson

    Description: http://www.picmicrochip.com
    Potential fix: http://www.picmicrochip.com/dl/cdc.h


    Problem:
    The DTE_PRESENT and CARRIER_CONTROL bits do not report the line state. Therefore, there is no way to tell if the host is ready for communication.

    Resolution:
    The structure (CONTROL_SIGNAL_BITMAP) in "/system/usb/class/cdc/cdc.h" is improperly defined. It defines (2) words (32 bits) where the intent was actually (2) bits.


     
    Edit: the website is gone. So I just posted the modified cdc.h here:
     

     /*********************************************************************
     *
     *             Microchip USB C18 Firmware -  CDC Version 1.0
     *
     *********************************************************************
     * FileName:        cdc.h
     * Dependencies:    See INCLUDES section below
     * Processor:       PIC18
     * Compiler:        C18 2.30.01+
     * Company:         Microchip Technology, Inc.
     *
     * Software License Agreement
     *
     * The software supplied herewith by Microchip Technology Incorporated
     * (the “Company”) for its PICmicro® Microcontroller is intended and
     * supplied to you, the Company’s customer, for use solely and
     * exclusively on Microchip PICmicro Microcontroller products. The
     * software is owned by the Company and/or its supplier, and is
     * protected under applicable copyright laws. All rights are reserved.
     * Any use in violation of the foregoing restrictions may subject the
     * user to criminal sanctions under applicable laws, as well as to
     * civil liability for the breach of the terms and conditions of this
     * license.
     *
     * THIS SOFTWARE IS PROVIDED IN AN “AS IS” CONDITION. NO WARRANTIES,
     * WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT NOT LIMITED
     * TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
     * PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. THE COMPANY SHALL NOT,
     * IN ANY CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL OR
     * CONSEQUENTIAL DAMAGES, FOR ANY REASON WHATSOEVER.
     *
     * Author               Date        Comment
     *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     * Rawin Rojvanit       7/21/04     Original.
     ********************************************************************/
    #ifndef CDC_H
    #define CDC_H
    /** I N C L U D E S **********************************************************/
    #include "system\typedefs.h"
    /** D E F I N I T I O N S ****************************************************/
    /* Class-Specific Requests */
    #define SEND_ENCAPSULATED_COMMAND   0x00
    #define GET_ENCAPSULATED_RESPONSE   0x01
    #define SET_COMM_FEATURE            0x02
    #define GET_COMM_FEATURE            0x03
    #define CLEAR_COMM_FEATURE          0x04
    #define SET_LINE_CODING             0x20
    #define GET_LINE_CODING             0x21
    #define SET_CONTROL_LINE_STATE      0x22
    #define SEND_BREAK                  0x23
    /* Notifications *
     * Note: Notifications are polled over
     * Communication Interface (Interrupt Endpoint)
     */
    #define NETWORK_CONNECTION          0x00
    #define RESPONSE_AVAILABLE          0x01
    #define SERIAL_STATE                0x20

    /* Device Class Code */
    #define CDC_DEVICE                  0x02
    /* Communication Interface Class Code */
    #define COMM_INTF                   0x02
    /* Communication Interface Class SubClass Codes */
    #define ABSTRACT_CONTROL_MODEL      0x02
    /* Communication Interface Class Control Protocol Codes */
    #define V25TER                      0x01    // Common AT commands ("Hayes(TM)")

    /* Data Interface Class Codes */
    #define DATA_INTF                   0x0A
    /* Data Interface Class Protocol Codes */
    #define NO_PROTOCOL                 0x00    // No class specific protocol required

    /* Communication Feature Selector Codes */
    #define ABSTRACT_STATE              0x01
    #define COUNTRY_SETTING             0x02
    /* Functional Descriptors */
    /* Type Values for the bDscType Field */
    #define CS_INTERFACE                0x24
    #define CS_ENDPOINT                 0x25
    /* bDscSubType in Functional Descriptors */
    #define DSC_FN_HEADER               0x00
    #define DSC_FN_CALL_MGT             0x01
    #define DSC_FN_ACM                  0x02    // ACM - Abstract Control Management
    #define DSC_FN_DLM                  0x03    // DLM - Direct Line Managment
    #define DSC_FN_TELEPHONE_RINGER     0x04
    #define DSC_FN_RPT_CAPABILITIES     0x05
    #define DSC_FN_UNION                0x06
    #define DSC_FN_COUNTRY_SELECTION    0x07
    #define DSC_FN_TEL_OP_MODES         0x08
    #define DSC_FN_USB_TERMINAL         0x09
    /* more.... see Table 25 in USB CDC Specification 1.1 */
    /* CDC Bulk IN transfer states */
    #define CDC_TX_READY                0
    #define CDC_TX_BUSY                 1
    #define CDC_TX_BUSY_ZLP             2       // ZLP: Zero Length Packet
    #define CDC_TX_COMPLETING           3
    // Travis Robinson 03/2007 - [link=http://www.picmcrochip.com]www.picmcrochip.com[/link]
    // <!MOD!>: Fix set_control_line_state bug
    // Add macros for checking the control signal bits
    #define mUSBUSARTIsDTR() control_signal_bitmap.DTE_PRESENT
    #define mUSBUSARTIsRTS() control_signal_bitmap.CARRIER_CONTROL
    /******************************************************************************
     * Macro:           BOOL mUSBUSARTIsTxTrfReady(void)
     *
     * PreCondition:    None
     *
     * Input:           None
     *
     * Output:          None
     *
     * Side Effects:    None
     *
     * Overview:        This macro is used to check if the CDC class is ready
     *                  to send more data.
     *                  Typical Usage: if(mUSBUSARTIsTxTrfReady())
     *
     * Note:            None
     *****************************************************************************/
    #define mUSBUSARTIsTxTrfReady()     (cdc_trf_state == CDC_TX_READY)
    /******************************************************************************
     * Macro:           (bit) mCDCUsartRxIsBusy(void)
     *
     * PreCondition:    None
     *
     * Input:           None
     *
     * Output:          None
     *
     * Side Effects:    None
     *
     * Overview:        This macro is used to check if CDC bulk OUT endpoint is
     *                  busy (owned by SIE) or not.
     *                  Typical Usage: if(mCDCUsartRxIsBusy())
     *
     * Note:            None
     *****************************************************************************/
    #define mCDCUsartRxIsBusy()         CDC_BULK_BD_OUT.Stat.UOWN
    /******************************************************************************
     * Macro:           (bit) mCDCUsartTxIsBusy(void)
     *
     * PreCondition:    None
     *
     * Input:           None
     *
     * Output:          None
     *
     * Side Effects:    None
     *
     * Overview:        This macro is used to check if CDC bulk IN endpoint is
     *                  busy (owned by SIE) or not.
     *                  Typical Usage: if(mCDCUsartTxIsBusy())
     *
     * Note:            None
     *****************************************************************************/
    #define mCDCUsartTxIsBusy()         CDC_BULK_BD_IN.Stat.UOWN
    /******************************************************************************
     * Macro:           byte mCDCGetRxLength(void)
     *
     * PreCondition:    None
     *
     * Input:           None
     *
     * Output:          mCDCGetRxLength returns cdc_rx_len
     *
     * Side Effects:    None
     *
     * Overview:        mCDCGetRxLength is used to retrieve the number of bytes
     *                  copied to user's buffer by the most recent call to
     *                  getsUSBUSART function.
     *
     * Note:            None
     *****************************************************************************/
    #define mCDCGetRxLength()           cdc_rx_len
    /******************************************************************************
     * Macro:           void mUSBUSARTTxRam(byte *pData, byte len)
     *
     * PreCondition:    cdc_trf_state must be in the CDC_TX_READY state.
     *                 
     *                  Value of 'len' must be equal to or smaller than 255 bytes.
     *
     * Input:           pDdata  : Pointer to the starting location of data bytes
     *                  len     : Number of bytes to be transferred
     *
     * Output:          None
     *
     * Side Effects:    None
     *
     * Overview:        Use this macro to transfer data located in data memory.
     *                  Use this macro when:
     *                  1. Data stream is not null-terminated
     *                  2. Transfer length is known
     *
     *                  Remember: cdc_trf_state must == CDC_TX_READY
     *                  Unlike putsUSBUSART, there is not code double checking
     *                  the transfer state. Unexpected behavior will occur if
     *                  this function is called when cdc_trf_state != CDC_TX_READY
     *
     * Note:            This macro only handles the setup of the transfer. The
     *                  actual transfer is handled by CDCTxService().
     *****************************************************************************/
    #define mUSBUSARTTxRam(pData,len)   \
    {                                   \
        pCDCSrc.bRam = pData;           \
        cdc_tx_len = len;               \
        cdc_mem_type = _RAM;            \
        cdc_trf_state = CDC_TX_BUSY;    \
    }
    /******************************************************************************
     * Macro:           void mUSBUSARTTxRom(rom byte *pData, byte len)
     *
     * PreCondition:    cdc_trf_state must be in the CDC_TX_READY state.
     *                 
     *                  Value of 'len' must be equal to or smaller than 255 bytes.
     *
     * Input:           pDdata  : Pointer to the starting location of data bytes
     *                  len     : Number of bytes to be transferred
     *
     * Output:          None
     *
     * Side Effects:    None
     *
     * Overview:        Use this macro to transfer data located in program memory.
     *                  Use this macro when:
     *                  1. Data stream is not null-terminated
     *                  2. Transfer length is known
     *
     *                  Remember: cdc_trf_state must == CDC_TX_READY
     *                  Unlike putrsUSBUSART, there is not code double checking
     *                  the transfer state. Unexpected behavior will occur if
     *                  this function is called when cdc_trf_state != CDC_TX_READY
     *
     * Note:            This macro only handles the setup of the transfer. The
     *                  actual transfer is handled by CDCTxService().
     *****************************************************************************/
    #define mUSBUSARTTxRom(pData,len)   \
    {                                   \
        pCDCSrc.bRom = pData;           \
        cdc_tx_len = len;               \
        cdc_mem_type = _ROM;            \
        cdc_trf_state = CDC_TX_BUSY;    \
    }
    /** S T R U C T U R E S ******************************************************/
    /* Line Coding Structure */
    #define LINE_CODING_LENGTH          0x07
    typedef union _LINE_CODING
    {
        struct
        {
            byte _byte[LINE_CODING_LENGTH];
        };
        struct
        {
            DWORD   dwDTERate;          // Complex data structure
            byte    bCharFormat;
            byte    bParityType;
            byte    bDataBits;
        };
    } LINE_CODING;
    typedef union _CONTROL_SIGNAL_BITMAP
    {
        byte _byte;
        struct
        {
    // Travis Robinson 03/2007 - [link=http://www.picmcrochip.com]www.picmcrochip.com[/link]
    // <!MOD!>: Fix set_control_line_state bug
    //  This produces a structure with (2) bytes.
    //  The intention was (2) bits.
    //
    //        unsigned DTE_PRESENT;       // [0] Not Present  [1] Present
    //        unsigned CARRIER_CONTROL;   // [0] Deactivate   [1] Activate
    //  Here is (2) bits..
            unsigned DTE_PRESENT:1;       // [0] Not Present  [1] Present
            unsigned CARRIER_CONTROL:1;   // [0] Deactivate   [1] Activate
        };
    } CONTROL_SIGNAL_BITMAP;

    /* Functional Descriptor Structure - See CDC Specification 1.1 for details */
    /* Header Functional Descriptor */
    typedef struct _USB_CDC_HEADER_FN_DSC
    {
        byte bFNLength;
        byte bDscType;
        byte bDscSubType;
        word bcdCDC;
    } USB_CDC_HEADER_FN_DSC;
    /* Abstract Control Management Functional Descriptor */
    typedef struct _USB_CDC_ACM_FN_DSC
    {
        byte bFNLength;
        byte bDscType;
        byte bDscSubType;
        byte bmCapabilities;
    } USB_CDC_ACM_FN_DSC;
    /* Union Functional Descriptor */
    typedef struct _USB_CDC_UNION_FN_DSC
    {
        byte bFNLength;
        byte bDscType;
        byte bDscSubType;
        byte bMasterIntf;
        byte bSaveIntf0;
    } USB_CDC_UNION_FN_DSC;
    /* Call Management Functional Descriptor */
    typedef struct _USB_CDC_CALL_MGT_FN_DSC
    {
        byte bFNLength;
        byte bDscType;
        byte bDscSubType;
        byte bmCapabilities;
        byte bDataInterface;
    } USB_CDC_CALL_MGT_FN_DSC;
    /** E X T E R N S ************************************************************/
    extern byte cdc_rx_len;
    extern byte cdc_trf_state;
    extern POINTER pCDCSrc;
    extern byte cdc_tx_len;
    extern byte cdc_mem_type;
    // Travis Robinson 03/2007 - [link=http://www.picmcrochip.com]www.picmcrochip.com[/link]
    // <!MOD!>: Fix set_control_line_state bug
    // extern the control_signal_bitmap var so we can
    // access it globally
    extern CONTROL_SIGNAL_BITMAP control_signal_bitmap;
    /** P U B L I C  P R O T O T Y P E S *****************************************/
    void USBCheckCDCRequest(void);
    void CDCInitEP(void);
    byte getsUSBUSART(unsigned char *buffer, byte len);
    void putrsUSBUSART(unsigned const rom char *data);
    void putsUSBUSART(unsigned char *data);
    void CDCTxService(void);
    #endif //CDC_H


    post edited by xiaofan - 2008/04/19 21:30:23
    #7
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 06:31:26 (permalink)
    0
    Unconfirmed: enable the extended instruction and the firmware may not work
    Report: I've read some reports that the bootloader and the HID example may not work if the extended instruction set is enabled.
     
    This proved to be wrong. It should work.
    post edited by xiaofan - 2008/04/19 21:31:05
    #8
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 06:34:56 (permalink)
    0
    9. Confirmed: lack of documentation and examples...

    Edit: I need to be more positive and constructive so I add the following potential fix.
    Potential fix:
    1) Efforts by the community. People like Pacer and Brad Minch have contributed a lot to this forum section. So we can overcome many problems and indeed get things done.
    2) More efforts from Microchip: better documentation, bug fixes, more examples, more resources. I believe Microchip is a great company and I am sure they will listen to the feedback just as before.
    post edited by xiaofan - 2007/08/15 06:40:50
    #9
    mzoran
    Super Member
    • Total Posts : 683
    • Reward points : 0
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 13:07:49 (permalink)
    0
    In regards to #9, I wish the forum had a sticky topic, the Microchip website had a better USB page, or the processor document had an appendix to list references to general USB resources.  When I first got started with USB, I didn't find the USB module documentation of the processor docs particularly illuminating since it assumes you are already very advanced on your USB skills.  I've generally found the Microchip pages on USB to be very useful but the pages tend to be burried in the website and hard to find.   It took me awhile just to find the USB framework code sample.  Also, as people advance questions tend to become more about how to deal with Windows or Linux rather then about Microchip products.
     
    What I'm saying is that alot of information and resources are floating around on the web, through books, and topics on this forum that range in skill level from newbee to expert, it just isn't compiled into a easy to find readily accessable list of resources.    
    #10
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 16:55:23 (permalink)
    0
    10. USBStdGetDscHandler should STALL unsupported Descriptor request (found by Dario)
    http://forum.microchip.com/tm.aspx?m=271023
     
     
    The following code does not handle the unsupported descriptor request.
     

      void USBStdGetDscHandler(void) {

      if(SetupPkt.bmRequestType == 0x80) {
        switch(SetupPkt.bDscType) {
          case DSC_DEV:
            ctrl_trf_session_owner = MUID_USB9;
            pSrc.bRom = (rom byte*)&device_dsc;
            wCount._word = sizeof(device_dsc);          // Set data count
            break;
          case DSC_CFG:
            ctrl_trf_session_owner = MUID_USB9;
            pSrc.bRom = *(USB_CD_Ptr+SetupPkt.bDscIndex);
            wCount._word = *(pSrc.wRom+1);              // Set data count
            break;
          case DSC_STR:
            ctrl_trf_session_owner = MUID_USB9;
            pSrc.bRom = *(USB_SD_Ptr+SetupPkt.bDscIndex);
            wCount._word = *pSrc.bRom;                  // Set data count
            break;
          } //end switch
           
        usb_stat.ctrl_trf_mem = _ROM;                       // Set memory type
        } //end if
        } //end USBStdGetDscHandler
     

     
    Potential fix (untested): please refer to that thread for the potential fix by Dario.
    #11
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/15 17:00:08 (permalink)
    0
    ORIGINAL: mzoran
    What I'm saying is that alot of information and resources are floating around on the web, through books, and topics on this forum that range in skill level from newbee to expert, it just isn't compiled into a easy to find readily accessable list of resources.    

     
    I agree and I am trying to do a little bit to compile some information (useful websites, forum posts, etc).
     
    Certainly the broken forum software does not help here (many attachements got lost...).
    #12
    lbodnar
    Super Member
    • Total Posts : 1148
    • Reward points : 0
    • Joined: 2005/12/18 06:06:09
    • Location: UK
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/16 01:22:37 (permalink)
    0
    Great idea to compile it all in one thread!
    ORIGINAL: xiaofan
    4. ACTVIF bug in usbdrv.c (USBWakeFromSuspend)...
    I think there are some other discussions on this but I just could not find it right now.

    http://forum.microchip.com/tm.aspx?m=138617


    Leo
    #13
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/20 12:40:02 (permalink)
    0
    Yep, I agree with Leo: thank you Xiaofan!

    GENOVA :D :D ! GODO
    #14
    SugarCreek
    Senior Member
    • Total Posts : 180
    • Reward points : 0
    • Joined: 2004/09/10 16:40:56
    • Location: Indianapolis USA
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/26 08:31:18 (permalink)
    0
    ORIGINAL: xiaofan

    ORIGINAL: mzoran
    What I'm saying is that alot of information and resources are floating around on the web, through books, and topics on this forum that range in skill level from newbee to expert, it just isn't compiled into a easy to find readily accessable list of resources.    


    I agree and I am trying to do a little bit to compile some information (useful websites, forum posts, etc).

    Certainly the broken forum software does not help here (many attachements got lost...).

    This prods me to share an idea with which I've been wrestling for a few months now...
     
    Looking at the swirl of interest created by Brad Minch's posting of an assembler version of the software, and taking into account the anomalies and shortcomings of the official MC C firmware framework, it seems to me that the Microchip user community has far more time, interest and/or priority in supporting the firmware than does Microchip corporate.
     
    Is it ludicrously impossible to suggest that we commission an open-source effort (or two efforts, perhaps: C and asm) to develop, to certify and to maintain a communal, user-driven firmware framework for Microchip USB, a la Linux?
     
    I have neither the time nor the expertise to head this up, but -- after wrestling with this for over a year -- I have several ideas for shaping the initial directions of the effort and the general model of the resulting software, and I could contribute occasional pieces as well.
    #15
    lbodnar
    Super Member
    • Total Posts : 1148
    • Reward points : 0
    • Joined: 2005/12/18 06:06:09
    • Location: UK
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/26 09:51:39 (permalink)
    0
    Very good idea, SugarCreek, but have you ever worked in a big corporation, preferably international with HQ in the US?
    If you haven't, the best you can do to acquaint yourself with corporate culture from the perspective of a person who actually does some productive work at the bottom is via reading Dilbert. grin
    It's a great idea but I can't see how it might work.

    Also, for majority of developers, USB is just a pipe. As soon as it pumps data as they need, they just move on to more interesting or more profitable things. The reason this forum is alive is because it didn't.

    USB range is expanding, new revisions of old silicon are coming out, to stay on the ball with the framework you have to be very close with the production and engineering to actually know of all the things others don't and probably never will. I can only quote Rumsfeld:
    "...as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know."

    Leo
    #16
    SugarCreek
    Senior Member
    • Total Posts : 180
    • Reward points : 0
    • Joined: 2004/09/10 16:40:56
    • Location: Indianapolis USA
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/26 13:48:54 (permalink)
    0
    ORIGINAL: lbodnar

    Very good idea, SugarCreek, but have you ever worked in a big corporation, preferably international with HQ in the US?
    If you haven't, the best you can do to acquaint yourself with corporate culture from the perspective of a person who actually does some productive work at the bottom is via reading Dilbert.
    It's a great idea but I can't see how it might work.
    Hmm... do I get at least partial credit for 20+ years in a (one-time) top-tier, multinational consumer electronics company with offices, laboratories and factories -- and 80,000 employees -- in 15 countries, variously as an embedded development engineer, technical sales engineer, business-development manager and defacto product manager?  Or perhaps for sitting on NEMA and UL working groups to debate and to develop new standards?  Or for being technical liaison between my company and a Japanese company, staying in Tokyo to facilitate the marriage of the technologies?
     
    My experience notwithstanding, I'm not sure that I see your point.  If you're trying to explain the inertia within Microchip, then you're preaching to the choir, because I'm intimately familiar with corporate constipation (and left my former job because of it).  If you're trying to forecast impossibility of a community-based effort, then I concede the enormity and complexity of the task, but I believe that we already have a fair portion of the foundation already in place with the regular contributors to this forum.
     
    Also, for majority of developers, USB is just a pipe. As soon as it pumps data as they need, they just move on to more interesting or more profitable things. The reason this forum is alive is because it didn't.
    I agree with you whole-heartedly on both counts.  As I've noted from my first appearance in this forum, USB should be "just a pipe", and yet the current state of the MC USB Firmware Framework makes this difficult if not unrealistic.  However, I'd like to think that after 20 or 30 of us all re-invent the wheel, at some point we could pool our efforts and produce something better for those who follow after us.

    USB range is expanding, new revisions of old silicon are coming out, to stay on the ball with the framework you have to be very close with the production and engineering to actually know of all the things others don't and probably never will.
    Again, I couldn't agree more.  It is for that very reason that I've lobbied long and hard for Microchip itself to take a more proactive position.  E-mails, telephone calls and face-to-face meetings have all yielded little, for a variety of valid and questionable reasons.  I even offered to fly to Arizona on my own dime and supply the necessary manpower under the direction and assistance of Microchip engineers, and I was politely rebuffed.
     
    From whatever combination of necessity and curiosity, there are a fair number of forum regulars here who probably know more about USB than Microchip, and then a bunch of us second-tier folk who have extensive battle experience if not authoritative expertise.  I'd even be willing to try to steer and to structure the effort, if there were a sufficient number of others who could lend their abilities.  Who knows, perhaps Microchip would even jump on the bandwagon once things got going.
    #17
    mzoran
    Super Member
    • Total Posts : 683
    • Reward points : 0
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/26 14:50:53 (permalink)
    0
    I worked as a engineer for a huge multinational corporation headquarted in the US where I worked at the bottom where real actual work got done.   I understand alot of what lbodnar is saying....
     
    I can totaly understand Microchip's position on this.  The framework is a sample.  Samples are ment as a learning tool and to get people started not to be used verbatum.  In large corporations samples are generally given very low priority and assigned to the lowest person on the todem pole.  The reason, it isn't contributing anything toward real actual product development.   From what I've seen, the "Important Customers" typically have expert people who have close working relationships with the product developers to get answers straight from the designers.  
     
    The corporation I worked for when I started had everybody constantly cloning code and reinventing the wheel which later changed to a strict policy of everything needs to be built out of reusable code.   IMHO, reusable code does not work for polished products.  From what I've seen, just as much or more energy gets put into dealing with bugs/problems of the reused module then it would take to solve the original problem without the module.    Then you get into issues such as the abstraction layer isn't exposing some simple bit in a hardware register and people start jumping through endless hoops to work around the lack of exposure.   Yes changes can be made to the framework to help people, but then you need a structure to decide which changes make it into the offical version and which do not. That's where things get political.
     
    From my projects, I think most Microchip firmware projects are on the small side. The Microchip framework is only about 1,000 lines of code. In the software world this is considered very small where a typical submodule is 50,000 to 100,000 lines of code.  That's were issues of reuse starts to become a necessary evil. 
     
    Sorry for ranting, this just hits a soft spot.
    #18
    lbodnar
    Super Member
    • Total Posts : 1148
    • Reward points : 0
    • Joined: 2005/12/18 06:06:09
    • Location: UK
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/26 15:34:29 (permalink)
    0
    ORIGINAL: SugarCreek
    Hmm... do I get at least partial credit for 20+ years in a (one-time) top-tier, multinational consumer electronics company with offices, laboratories and factories -- and 80,000 employees -- in 15 countries, variously as an embedded development engineer, technical sales engineer, business-development manager and defacto product manager?  Or perhaps for sitting on NEMA and UL working groups to debate and to develop new standards?  Or for being technical liaison between my company and a Japanese company, staying in Tokyo to facilitate the marriage of the technologies?
    ...
    E-mails, telephone calls and face-to-face meetings have all yielded little, for a variety of valid and questionable reasons.  I even offered to fly to Arizona on my own dime and supply the necessary manpower under the direction and assistance of Microchip engineers, and I was politely rebuffed.

    Of course you get the credit! grin But you have answered your own question. To write or maintain the framework one needs to at least know silicon internals possibly up to the mask level and have access to production testing tools. It is impossible in our context. Even obvious bugs presence was denied and they were later quietly published in errata or datasheets. It's not constructive attitude but there is very little competition for MC in this particular market segment so we have to live with it.

    All we do here is deconstructing a sample framework and finding some obvious bugs. We don't even understand how SIE works in non-trivial situations.

    Linux is supported and encouraged by open ubiquitous PC architecture that nobody owes. What would support this effort? I would hate to see a huge community effort going to waste when MC decides to change silicon again. 16C -> 18F migration was a good example. Why BSTALL flags changed their meaning along with some other changes? Nobody knows.

    As I said, it is a great thread! Like most, I try to contribute here from time to time but the information is so difficult to find here that I couldn't find my own errata posts when I needed them again wink If I come across as harsh or offensive, this was not my intention!

    Leo
    #19
    SugarCreek
    Senior Member
    • Total Posts : 180
    • Reward points : 0
    • Joined: 2004/09/10 16:40:56
    • Location: Indianapolis USA
    • Status: offline
    RE: USB Firmware Framework Confirmed and Potential Anomalies 2007/08/26 22:10:11 (permalink)
    0
    I, too, apologize if I'm sounding a little defensive or on a rant.  It's all just terribly frustrating to me, because I see where this could be so much easier and more productive for all concerned.  Granted, there's a fine line between being visionary and being delusional, but for the moment I'm holding onto the hope that I'm still visionary...
     
    And I actually do understand the surface-level logic of Microchip's position, although I disagree with its foundation (because an improved firmware framework should generate more design "wins" and therefore promote more sales) and the inconsistency of terminology (a complete stack or library is not the same as a demo or sample).
     
    ORIGINAL: lbodnar

    To write or maintain the framework one needs to at least know silicon internals possibly up to the mask level and have access to production testing tools. It is impossible in our context. Even obvious bugs presence was denied and they were later quietly published in errata or datasheets. It's not constructive attitude but there is very little competition for MC in this particular market segment so we have to live with it.

    All we do here is deconstructing a sample framework and finding some obvious bugs. We don't even understand how SIE works in non-trivial situations.
    As you point out, errata and shortcomings are often observed and articulated first by the user community.  While the underlying gate-level or timing-level analysis requires an "inside man", the detection (and often the workaround) can and routinely does occur among us customers.
     
    I would hate to see a huge community effort going to waste when MC decides to change silicon again. 16C -> 18F migration was a good example. Why BSTALL flags changed their meaning along with some other changes? Nobody knows.
    I agree that such a scenario is frustrating, but I suspect that it would be better recognized and adaptive action better taken communally rather than individually.  (One reason that I continue to follow the forum, even though I've got my first product in production, is that I'm scared to death that some flaw in silicon or firmware will pop through and I'll be either unaware of it or unable to tackle it on my own.)  As Benjamin Franklin is quoted as he signed the Declaration of Independence, "We must all hang together, or assuredly we shall all hang separately."

    As I said, it is a great thread! Like most, I try to contribute here from time to time but the information is so difficult to find here that I couldn't find my own errata posts when I needed them again
    We agree that this is a great thread, and I didn't intend to hijack it.  My thinking was that the next logical step, after communally documenting the shortcomings, was to address them communally.
    #20
    Page: 12345.. > >> Showing page 1 of 7
    Jump to:
    © 2020 APG vNext Commercial Version 4.5