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.

AM5746: USB2.0 issues with TI-RTOS

Part Number: AM5746

Hi,
My customers may fail USBD_bulkWrite.
We are currently working on a solution to this phenomenon.

Question 1:
We want to investigate this issue, but we can't find information about DWC3.
Would you provide information about the DWC3 userguide and registers map?
They are using USB_open (1,…) USB1 ("DWC3_1").

Question 2:
We don't know how to debug if USBD_bulkWrite fail.
Which registers (descriptor) should we look at?

Question 3:
I posted about the relationship with Eratta i819 before.
e2e.ti.com/.../833095
They saw the i819 workaround and modified the code.

C:\ti\pdk_am57xx_1_0_11\packages\ti\drv\usb\src\dwc\usb_dwc_dcd.c

Line:301
// HW_WR_FIELD32(dwc3->baseAddr + DWC_USB_DCFG, DWC_USB_DCFG_DEVSPD,
// DWC_USB_DCFG_DEVSPD_HS);
HW_WR_FIELD32(dwc3->baseAddr + DWC_USB_DCFG, DWC_USB_DCFG_DEVSPD,
DWC_USB_DCFG_DEVSPD_SS);

However, USBD_bulkWrite () fail.
Would you tell me specific examples of correction.

Question 4:
e2e.ti.com/.../833095
We don't understand what exactly happens to Eratta i819.
What phenomenon will happen?
Is this i819's trigger that "connect/disconnect the USB cable"?

ENV
 AM5746 Customer's board
 pdk_am57xx_1_0_11
 bios_6_76_00_08

 DWC3 as USB2.0

Regards,
Rei

  • Hi,

    All the USB registers are listed in AM57x TRM. Those DWC registers which are not listed need NDA.

    Below is errata:

    i819 A Device Control Bit Meta-Stability for USB3.0 Controller in USB2.0 Mode
    CRITICALITY Medium
    DESCRIPTION When USB3.0 controller core is programmed to be a USB 2.0-only device, possible
    hardware meta-stability on USB_DCTL[31] RUNSTOP bit causing the core to attempt
    high speed as well as SuperSpeed connection or completely miss the attach request.
    WORKAROUND If the requirement is to always function in USB 2.0 mode, there is no workaround.
    Otherwise, you can always program the USB controller core to be SuperSpeed 3.0
    capable (USB_DCFG[2:0] DEVSPD = 0x4).

    I don't see where we implemented the code for the workaround. In the USB driver, we used:

    /* Connect as high speed device */
    HW_WR_FIELD32(dwc3->baseAddr + DWC_USB_DCFG, DWC_USB_DCFG_DEVSPD,
    DWC_USB_DCFG_DEVSPD_HS);

    Can you confirm how do you test the USB in bulk mode, e.g. what PRSDK release, what USBV bulk example? What is the setup? The other side is a PC? With DEVSPD as HS, it worked as expected, correct? And when you change this to SS, the bulk write failed? 

    Do you want to use USB in 2.0 only?

    Regards, Eric 

  • Hi Eric-san,
    Thank you for your reply. I'm always helped by your comments.

    Eratta I819 WORKAROUND:
    Where should I modify? Would you tell me the source code?

    Is there no more information about the phenomenon of Eratta i819? My customers want to see if the phenomenon of Eratta matches their phenomenon.

    I will confirm with my customers, how they are testing, setup, USB2.0 only etc. Please wait a moment.

    Regards,
    Rei

  • Hi,

    Please answer this question too.

    Question 2:
    We don't know how to debug if USBD_bulkWrite fail.
    Which registers (descriptor) should we look at?

    Regards,

    Rei

  • Rei,

    I would ask customer if they were able to run the our example test as is at all. 

    There are many way the bulkWrite could fail during transfer. One of those way could be the host hasn’t asked for data transfer yet.  BulkWrite can only send data if the host has sent an IN token. A logic analyzer capture would show this is the case or not.

    Eratta I819 WORKAROUND:
    Where should I modify? Would you tell me the source code?

    This needs some time to find out. This errata info is from another business unit.

    Regards, Eric

  • Hi Rahul,
    Thank you for your reply. I ask customers if it can be reproduced with 574IDK and Sample project.
    And we wait for i819 information.

    I confirmed a little more about customers phenomenon.

    ■Sequence (e.g.)
    1. USBD_bulkRead().
    2. Analyze Read data...
    3. Make Resp data
    "USB go.go.go." -> 0xD Byte
    4. USBD_bulkWrite(0x5A, 0x0D, 0x00, len=3)
    1st Write is Data length.
    0x5A : data header.
    5. USBD_bulkWrite("USB go.go.go."+CRC(2 Byte), len=(0xD + 2))
    2nd Write is Data Body and CRC data(0x2 Byte) = 0xF Byte

    I received additional information from customers. They found a case what USBD_bulkWrite fail.

    (1) USBD_bulkWrite fail when the USB driver library created with “gmake usb” is linked.
    (2) USBD_bulkWrite do not fail when the USB driver library is imported CCS PJ.
    (use Overriding symbols)
    Instructions and Log : 

    Import USB Driver Code & Project Prop(Build Opt)
    
    
    - Add USB driver to CCS-PJ.
    
    <Our CCS PJ root>
    ��
    ����pdk1.0.11  
        ��  
        ��  
        ����ti
            ����drv
                ����usb
                    ��  Settings.h
                    ��  usbdaudio.h
                    ��  usbdbulk.h
                    ��  usbdmsc.h
                    ��  usbhmsc.h
                    ��  USBver.h
                    ��  usb_drv.h
                    ��  usb_osal.h
                    ��  
                    ����soc
                    ��  ����am574x
                    ��          hw_usb.h
                    ��          usb_soc.c
                    ��          usb_wrapper.c
                    ��          
                    ����src
                        ��  usb_drv.c
                        ��  
                        ����dwc
                        ��      hw_depcmdpar.h
                        ��      hw_dwc_usb.h
                        ��      hw_trb_device.h
                        ��      hw_usb_depcmd.h
                        ��      usb_dwc.c
                        ��      usb_dwc_dcd.c
                        ��      usb_dwc_dcd.h
                        ��      usb_hcd_xhci.h
                        ��      usb_xhci_hcd.c
                        ��      
                        ����include
                        ��      debug.h
                        ��      error.h
                        ��      hardware.h         [copy from C:\ti\pdk_am57xx_1_0_11\packages\ti\drv\usb\example\common\hardware.h]
                        ��      hw_types.h
                        ��      types.h
                        ��      usb-ids.h
                        ��      UsbDefs.h
                        ��      usb_bulk_structs.h
                        ��      usb_dcd_interface.h
                        ��      usb_dwc.h
                        ��      usb_spec_defines.h
                        ��      usb_wrapper.h
                        ��      
                        ����musb
                        ��      musb.h
                        ��      usb_musb_dcd.h
                        ��      
                        ����usb_func
                            ����common
                            ��      usbtick.c
                            ��      usb_desc.c
                            ��      
                            ����device
                            ��      usbdaudio.c.txt       [Unnecessary files]
                            ��      usbdbulk.c
                            ��      usbdcdesc.c
                            ��      usbdmsc.c
                            ��      usb_dcd_interface.c
                            ��      usb_dev_dman.c
                            ��      
                            ����host
                            ��      usbhenum_dwc.c
                            ��      usbhenum_musb.c.txt   [Unnecessary files]
                            ��      usbhmsc.c
                            ��      usbhscsi.c
                            ��      
                            ����include
                                    usbaudio.h
                                    usbdbulkint.h
                                    usbdevice.h
                                    usbhost.h
                                    usbhscsi.h
                                    usblib.h
                                    usblibpriv.h
                                    usbmsc.h
                                    usb_dev_dman.h
                                    usb_dev_object.h
                                    
    
    - Project prop (Add Include path)
    									<listOptionValue builtIn="false" value="${PROJECT_ROOT}/pdk1.0.11"/>
    									<listOptionValue builtIn="false" value="${PROJECT_ROOT}/pdk1.0.11/ti/drv/usb"/>
    									<listOptionValue builtIn="false" value="${PROJECT_ROOT}/pdk1.0.11/ti/drv/usb/src/include"/>
    									<listOptionValue builtIn="false" value="${PROJECT_ROOT}/pdk1.0.11/ti/drv/usb/src"/>
    									<listOptionValue builtIn="false" value="${PROJECT_ROOT}/pdk1.0.11/ti/drv/usb/src/dwc"/>
    									<listOptionValue builtIn="false" value="${PROJECT_ROOT}/pdk1.0.11/ti/drv/usb/src/musb"/>
    									<listOptionValue builtIn="false" value="${PROJECT_ROOT}/pdk1.0.11/ti/drv/usb/src/usb_func/include"/>
    									<listOptionValue builtIn="false" value="${PROJECT_ROOT}/pdk1.0.11/ti/drv/usb/soc/am574x"/>
    
    
    - delete at cfg file
      Unnecessary ti.drv.usb.aa15fg !
    //  del usb
    //  var Usb = xdc.loadPackage('ti.drv.usb');
    //  var usbSettings = xdc.useModule('ti.drv.usb.Settings');
    //  usbSettings.socType = socType;
    //  del usb
    
    
    
    - Our CCS PJ Build opt
    			<option id="com.ti.ccstudio.buildDefinitions.TMS470_GNU_6.0.compilerID.DEFINE.2008256722" name="Define symbols (-D)" superClass="com.ti.ccstudio.buildDefinitions.TMS470_GNU_6.0.compilerID.DEFINE" valueType="definedSymbols">
    				<listOptionValue builtIn="false" value="${EDMA3_LLD_SYMBOLS}"/>
    				<listOptionValue builtIn="false" value="${NDK_SYMBOLS}"/>
    				<listOptionValue builtIn="false" value="${TI_PDK_SYMBOLS}"/>
    				<listOptionValue builtIn="false" value="${BIOS_SYMBOLS}"/>
    				<listOptionValue builtIn="false" value="am5748"/>
    				<listOptionValue builtIn="false" value="core0"/>
    				<listOptionValue builtIn="false" value="idkAM574x"/>
    				<listOptionValue builtIn="false" value="SOC_AM574x"/>
    				<listOptionValue builtIn="false" value="gcc"/>
    			</option>
    
    
    			<option id="com.ti.ccstudio.buildDefinitions.TMS470_GNU_6.0.compilerID.ASM_SPECIFIC_FLAGS.928269240" name="Miscellaneous assembly source specific flags" superClass="com.ti.ccstudio.buildDefinitions.TMS470_GNU_6.0.compilerID.ASM_SPECIFIC_FLAGS" valueType="stringList">
    				<listOptionValue builtIn="false" value="-x assembler-with-cpp"/>
    			</option>
    
    			<option id="com.ti.ccstudio.buildDefinitions.TMS470_GNU_6.0.compilerID.OTHER_FLAGS.393051900" name="Miscellaneous flags" superClass="com.ti.ccstudio.buildDefinitions.TMS470_GNU_6.0.compilerID.OTHER_FLAGS" valueType="stringList">
    				<listOptionValue builtIn="false" value="-c"/>
    				<listOptionValue builtIn="false" value="-mlittle-endian"/>
    				<listOptionValue builtIn="false" value="-mno-unaligned-access"/>
    				<listOptionValue builtIn="false" value="-fno-inline"/>
    			</option>
    
    
    ==== Build log (CCS) ========================
    
    	**** Build of configuration Debug for project OurProject ****
    
    	"C:\\ti\\ccsv8\\utils\\bin\\gmake" -j 4 all -O 
    	 
    	Building file: "../pdk1.0.11/ti/drv/usb/src/dwc/usb_dwc_dcd.c"
    	Invoking: GNU Compiler
    	"C:/ti/gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-gcc.exe" -c -mcpu=cortex-a15 -mtune=cortex-a15 -marm -mfloat-abi=hard -Dam5748 -Dcore0 -DidkAM574x -DSOC_AM574x -Dgcc -I"C:/ti/pdk_am57xx_1_0_11/packages"
    	 .... Include path ...
    	   :
    	-O2 -g -gdwarf-3 -gstrict-dwarf -c -mlittle-endian -mno-unaligned-access -fno-inline -MMD -MP -MF"pdk1.0.11/ti/drv/usb/src/dwc/usb_dwc_dcd.d" -MT"pdk1.0.11/ti/drv/usb/src/dwc/usb_dwc_dcd.o" -std=gnu99 @"configPkg/compiler.opt" -o"pdk1.0.11/ti/drv/usb/src/dwc/usb_dwc_dcd.o" "../pdk1.0.11/ti/drv/usb/src/dwc/usb_dwc_dcd.c"
    	Finished building: "../pdk1.0.11/ti/drv/usb/src/dwc/usb_dwc_dcd.c"
    	 
    	Building target: "OurProject.out"
    	Invoking: GNU Linker
    	Flags: -mtune=cortex-a15 -marm -Dam5748 -Dcore0 -DidkAM574x -DSOC_AM574x -Dgcc -O2 -g -gdwarf-3 -gstrict-dwarf -mlittle-endian -mno-unaligned-access -fno-inline -mfloat-abi=hard -Wl,-Map,"OurProject.map" -nostartfiles -static -Wl,--gc-sections -L"C:/ti/bios_6_76_00_08/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/hard" -Wl,--defsym,CORE0=1 -Wl,--defsym,STACKSIZE=0x10000 -Wl,--defsym,HEAPSIZE=0x400 --specs=nano.specs -static C:/ti/pdk_am57xx_1_0_11/packages/ti/drv/icss_emac/firmware/icss_dualemac/bin/am574x/a15_0/REV2/icss_dualemac_PRU0.bin C:/ti/pdk_am57xx_1_0_11/packages/ti/drv/icss_emac/firmware/icss_dualemac/bin/am574x/a15_0/REV2/icss_dualemac_PRU1.bin
    	"C:/ti/gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-gcc.exe" @"ccsLinker.opt" -o"OurProject.out"
    	Finished building target: "OurProject.out"
    	 
    
    	**** Build Finished ****
    
    
    
    
    
    ==== Build log (gmake) ==================
    
    	This program built for Windows32
    	Reading makefiles...
    	Updating goal targets....
    	 File `comp_libs' does not exist.
    	   File `usb' does not exist.
    	  Must remake target `usb'.
    	gmake[4]: Entering directory `C:/ti/pdk_am57xx_1_0_11/packages/ti/drv/usb'
    	gmake -C C:/ti/pdk_am57xx_1_0_11/packages/ti/drv/usb -f build/makefile.mk
    	GNU Make 3.81
    	Copyright (C) 2006  Free Software Foundation, Inc.
    	This is free software; see the source for copying conditions.
    	There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
    	PARTICULAR PURPOSE.
    
    	This program built for Windows32
    	Reading makefiles...
    	gmake[5]: Entering directory `C:/ti/pdk_am57xx_1_0_11/packages/ti/drv/usb'
    	C:/ti/pdk_am57xx_1_0_11/packages/ti/build/makerules/rules_a15.mk:149: target `package/all/src/dwc' given more than once in the same rule.
    	Updating goal targets....
    	 File `all' does not exist.
    	   File `a15_0' does not exist.
    	        Must remake target `C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release'.
    	C:/ti/xdctools_3_50_03_33_core/bin/mkdir -p C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release
    	        Successfully remade target file `C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release'.
    	        Must remake target `C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/.deps'.
    	C:/ti/xdctools_3_50_03_33_core/bin/mkdir -p C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/.deps
    	        Successfully remade target file `C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/.deps'.
    	      Must remake target `C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/usb_drv.oa15fg'.
    	# Compiling am574x:a15_0:release:usb: src/usb_drv.c
    	C:/ti/gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-gcc -MD -MF C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/.deps/usb_drv.P -DMAKEFILE_BUILD -Wimplicit -Wall -Wunused -Wunknown-pragmas -ffunction-sections -fdata-sections -c -mcpu=cortex-a15 -g -mfpu=neon -mfloat-abi=hard -mabi=aapcs -mapcs-frame -D__ARMv7 -Werror -O2 -s -DNDEBUG -Dgcc  -DBUILD_A15_0 -mno-unaligned-access    -DSOC_AM574x -IC:/ti/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include -IC:/ti/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/newlib-nano -I. -Isrc -Isrc/usb_func/common -Isrc/usb_func/device -Isrc/usb_func/host -Isrc/include -Isrc/usb_func/include -Isrc/musb -Isoc/am574x -Isrc/dwc -Isoc -Isoc/am574x -IC:/ti/pdk_am57xx_1_0_11/packages -IC:/ti/edma3_lld_2_12_05_30C/packages -I/apps/apps_nonbam/inc -I/ -I/common  -o C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/usb_drv.oa15fg src/usb_drv.c
    	      Successfully remade target file `C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/usb_drv.oa15fg'.
    	      Must remake target `C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/usb_desc.oa15fg'.
    
    
    	# Compiling am574x:a15_0:release:usb: src/dwc/usb_dwc_dcd.c
    	C:/ti/gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-gcc -MD -MF C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/.deps/usb_dwc_dcd.P -DMAKEFILE_BUILD -Wimplicit -Wall -Wunused -Wunknown-pragmas -ffunction-sections -fdata-sections -c -mcpu=cortex-a15 -g -mfpu=neon -mfloat-abi=hard -mabi=aapcs -mapcs-frame -D__ARMv7 -Werror -O2 -s -DNDEBUG -Dgcc  -DBUILD_A15_0 -mno-unaligned-access    -DSOC_AM574x -IC:/ti/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include -IC:/ti/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/newlib-nano -I. -Isrc -Isrc/usb_func/common -Isrc/usb_func/device -Isrc/usb_func/host -Isrc/include -Isrc/usb_func/include -Isrc/musb -Isoc/am574x -Isrc/dwc -Isoc -Isoc/am574x -IC:/ti/pdk_am57xx_1_0_11/packages -IC:/ti/edma3_lld_2_12_05_30C/packages -I/apps/apps_nonbam/inc -I/ -I/common  -o C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/usb_dwc_dcd.oa15fg src/dwc/usb_dwc_dcd.c
    	      Successfully remade target file `C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/usb_dwc_dcd.oa15fg'.
    	      Must remake target `C:/ti/pdk_am57xx_1_0_11/packages/ti/binary/ti/drv/usb/usb/obj/am574x/a15/release/usb_dwc.oa15fg'.
    
    

    Question:
    Why is this happening? When writing in product, (1) is recommended.
    So we would like to work with the procedure in (1).

    Regards,
    Rei

  • Hi,

    (1) USBD_bulkWrite fail when the USB driver library created with “gmake usb” is linked.
    (2) USBD_bulkWrite do not fail when the USB driver library is imported CCS PJ.
    (use Overriding symbols)
    Instructions and Log : ADD_usb_drv_to_CCS.txt

    Question:
    Why is this happening? When writing in product, (1) is recommended.
    So we would like to work with the procedure in (1).

    Let me explain:

    • The USB library is always build by gmake.
    • The USB CCS project always uses the USB library built by gmake. We don't see any failure of USB bulk test. 
    • TI doesn't provide CCS project to build USB library.
    • It looked your customer added all the USB driver source codes and headers into the application and build it, then he removed the existing USB library from gmake. And this worked.  

    My question to your customer: using TI USB driver and test application as it is, are you able to see the bulk write failure?

    Regards, Eric

  • Hi Eric,
    Thank you for your reply.

    My question to your customer: using TI USB driver and test application as it is, are you able to see the bulk write failure?
    -->I confirm it to the customers.

    They created an example that USBD_bulk failed.
    (Based on USB_DevBulk_idkAM574x_armExampleProject)

    LC_USB_DevBulk_idkAM574x_armExampleProject0906.zip
    Dev_bulk_main.c/usb_bulk_structs.c in the uploaded project Overwriting USB_DevBulk_idkAM574x_armExampleProject will result in the sequence they are saying.

    If Read/Write is size 0 (failure), they are making it into an infinite loop.

    If the HOST continues to input 512 bytes toward the device that wrote this PJ, it seems that the failure of Write / Read can be confirmed.
    (The host side (PC) applications they use are private and cannot be uploaded)

    Question:
    Is this procedure (_make_pj_info.txt) correct when including the USB driver?

    Rei

  • Hi,

    This was discussed in the e-mail, and captured below for record:

    The AM574x has two USB ports, the port0 supports the USB 3.0 (SS, HS, FS) and port1 supports USB 2.0 (HS, FS). The Errata i819 was written by the auto motive BU and I don’t have the background, original author and test case. Based on the Errata recommendation, our AM57x Processors SDK RTOS source code use the USB 2.0 configuration, this is correct.

     

        /* Connect as high speed device */

        HW_WR_FIELD32(dwc3->baseAddr + DWC_USB_DCFG, DWC_USB_DCFG_DEVSPD,

                      DWC_USB_DCFG_DEVSPD_HS);

     

    Also, the USB device mode (like bulk) we only support HS and FS in RTOS, that is why in our source code we used instance 1 (0-based). In your attached CCS project, I saw you also used the same instance 1 (this only supports USB 2.0). The RTOS USB driver code looks correct, there is no need to change the DWC_USB_DCFG_DEVSPD from DWC_USB_DCFG_DEVSPD_HS (0) to DWC_USB_DCFG_DEVSPD_SS (4). We checked DWC data book and confirmed the DWC_USB_DCFG register DEVSPD bit field and coding, the RTOS code usage is correct.

     

    /* on idkAM572x, USB1 is attached to a USB device connector */

    #define USB_DEV_INSTANCE                     1

    #define DWC_USB_DCFG_DEVSPD_SHIFT                               (0U)

    #define DWC_USB_DCFG_DEVSPD_MASK                                (0x00000007U)

    #define DWC_USB_DCFG_DEVSPD_HS                                   (0U)

    #define DWC_USB_DCFG_DEVSPD_FS                                   (1U)

    #define DWC_USB_DCFG_DEVSPD_SS                                   (4U)

     

    What is the reason that customer change this to DWC_USB_DCFG_DEVSPD_SS? I also changed this to SS and tested the USB_DevBulk_idkAM574x_armExampleProject, it still worked for me.

    For the bulk_write failure, I noticed below sequence in your test code:

    g_wt1_len = USBD_bulkWrite(usb_handle, &g_bulkTxBuffer[0], 3);

     

                if ((g_wt1_len != 3) && ((g_ulFlags & COMMAND_STATUS_UPDATE) == 0)) {

                                                                // Sometimes READ/WRITE fails.

                                                                fnFatal( 0x1002 ) ;

                                                 }

     

                // ... CRC(2 Byte) was omitted.

                // TESTTEST add-E

     

                convertData(g_bulkRxBuffer, /* *incomingPcData, */

                            g_bulkTxBuffer, /* *outgoingPcData */

                            rxBytes);

     

    // TESTTEST             USBD_bulkWrite(usb_handle, g_bulkTxBuffer, rxBytes);

                g_wt2_len = USBD_bulkWrite(usb_handle, g_bulkTxBuffer, rxBytes);

     

    That is there are two successive  USBD_bulkWrite() API calls. I don’t have details from your host application, does the host expect two USB IN requests?

    Regards, Eric 

  • Hi,

    Same issue discussed in https://e2e.ti.com/support/processors/f/791/t/839554, closing this one.

    Regards, Eric

  • Hi Eric,

    Thank you so much for checking. In another thread, USB issue has been cleared.
    However, there is a discussion that I want to continue here.

    My customers are worried about Eratta i819. They use USB2.0, but can't understand what kind of failure will happen in what situation. If we know the details of this errata, we can think of a countermeasure.

    Question 1:
    I looked at your explanation. Eratta i819 workaround is already reflected in USB driver.
    Is this correct?

    Question 2:
    Could you ask for information about Eratta i819 from Auto motive BU?
    (What kind of trouble will occur under what situations?)

    I'm always grateful for your help.

    Best regards,
    Rei

  • Hi,

    For Q1, it is correct.

    For Q2, Let me check.

    Regards, Eric

  • Hi Eric,

    Any updates?

    Regards, Rei

  • Sorry, no, I don't have any information about errata i819, the document was writing by another business unit. 

    Regards, Eric