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.

CCS/TM4C123FH6PM: USB Host MSC Application Device Never Gets Enumerated

Part Number: TM4C123FH6PM
Other Parts Discussed in Thread: EK-TM4C1294XL, , TPD4S012, EK-TM4C123GXL

Tool/software: Code Composer Studio

Hello Everyone,

I am having trouble on the msc application on my custom pcb. I first developed an application to read data from a flash stick with the fat file system and ran it on ek-tm4c1294xl development kit. 

Now I am trying to port the same application to the tm4c123fh6pm chip I am using. 

The following differences are present on my pcb. 

The processor runs without a crystal from the internal oscillator with pll at 80 mhz. 

There is a Power-Distribution Switch present to monitor VBUS. This chip has an active low enable connected to EPEN signal from the chip.

Instead of TPD4S012, the design has USBLC6-2 for ESD protection. 

There is USB-A and Micro-USB ports present on the design (they are connected to the same DP, DM, VBUS and GND lines) but only 1 device is plugged in, I just needed to test both for functionality but only 1 will remain in the final design.

The changes I made are following:

TM4C129 configuration: 

    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = 0xff;
    ROM_GPIOPinConfigure(GPIO_PD6_USB0EPEN); 
    ROM_GPIOPinTypeUSBAnalog(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1); 
    ROM_GPIOPinTypeUSBDigital(GPIO_PORTD_BASE, GPIO_PIN_6);
    ROM_GPIOPinTypeUSBAnalog(GPIO_PORTL_BASE, GPIO_PIN_6 | GPIO_PIN_7);
    ROM_GPIOPinTypeGPIOInput(GPIO_PORTQ_BASE, GPIO_PIN_4);

    //
    // Initialize the USB stack mode and pass in a mode callback.
    //
    USBStackModeSet(0, eUSBModeHost, 0);

    //
    // Register the host class drivers.
    //
    USBHCDRegisterDrivers(0, g_ppHostClassDrivers, g_ui32NumHostClassDrivers);

    //
    // Open an instance of the mass storage class driver.
    //
    g_psMSCInstance = USBHMSCDriveOpen(0, MSCCallback);

    //
    // Initialize the power configuration.  This sets the power enable signal
    // to be active high and does not enable the power fault.
    //
    USBHCDPowerConfigInit(0, USBHCD_VBUS_AUTO_HIGH | USBHCD_VBUS_FILTER);

    //
    // Tell the USB library the CPU clock and the PLL frequency.  This is a
    // new requirement for TM4C129 devices.
    //
    SysCtlVCOGet(SYSCTL_XTAL_25MHZ, &ui32PLLRate);
    USBHCDFeatureSet(0, USBLIB_FEATURE_CPUCLK, &g_ui32SysClock);
    USBHCDFeatureSet(0, USBLIB_FEATURE_USBPLL, &ui32PLLRate);

    //
    // Initialize the USB controller for host operation.
    //
    USBHCDInit(0, g_pHCDPool, HCD_MEMORY_SIZE);

    //
    // Initialize the file system.
    //
    f_mount(0, &g_sFatFs);

TM4C123 Configuration:

    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = 0xff;
    ROM_GPIOPinConfigure(GPIO_PD2_USB0EPEN);
    ROM_GPIOPinTypeUSBAnalog(GPIO_PORTD_BASE, GPIO_PIN_4 | GPIO_PIN_5);
    ROM_GPIOPinTypeUSBDigital(GPIO_PORTD_BASE, GPIO_PIN_2);
    ROM_GPIOPinTypeUSBAnalog(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1);    
    //
    // Initialize the USB stack mode and pass in a mode callback.
    //
    USBStackModeSet(0, eUSBModeHost, 0);

    //
    // Register the host class drivers.
    //
    USBHCDRegisterDrivers(0, g_ppHostClassDrivers, g_ui32NumHostClassDrivers);

    //
    // Open an instance of the mass storage class driver.
    //
    g_psMSCInstance = USBHMSCDriveOpen(0, MSCCallback);

    //
    // Initialize the power configuration.  This sets the power enable signal
    // to be active low and does not enable the power fault.
    //
    USBHCDPowerConfigInit(0, USBHCD_VBUS_AUTO_LOW | USBHCD_VBUS_FILTER);

    SysCtlUSBPLLEnable();

    //
    // Initialize the USB controller for host operation.
    //
    USBHCDInit(0, g_pHCDPool, HCD_MEMORY_SIZE);

    //
    // Initialize the file system.
    //
    f_mount(0, &g_sFatFs);

The following changes have been made to port the code:

The clock configuration has been changed where applicable. (Systick etc.)

Instead of Feature Set and SysCtlVCOGet Calls for PLL SysCtlUSBPLLEnable call have been made.

Since system clock is 80 MHz USBHCDFeatureSet call for CPUCLK was omitted but I also tried the code by including it and passing the system value with a pointer but it didn't make any difference.

The startup file has the necessary interrupt handler functions. 

The pins have been changed. 

The rom defines were changed.

USBHCDPowerConfigInit was changed to accomodate EPEN as active low. 

I verify that VBUS is 5V and EPEN is low when the configuration is finished. ID also is low and device is connected to the Micro-USB slot.

The MSC Example was using the OTG Interrupt Handler and that is also what I configured it with. The OTG Interrupt never fires when a device is plugged in.

I make the necessary SysTick configuration and the interrupt handler is also in the vector table and firing.

I also tried eUSBModeForceHost but that also didn't work. It works on the TM4C129 dev board.

I am trying to find out what I missed while porting the code or If I am making a fundamental mistake.

I looked at USB Host MSC example from DK TM4C123 Board and that was actually using HCD Host instead of OTG on the function calls but If the interrupt is fired to detect the device OTG Main function also calls HCD Main function for detected devices. I didn't notice any major differences besides this. 

EDIT: I also tried just jumping DP and DM pins to the TM4C129 device and supplying the power from TM4C123 device for VBUS with the correct EPEN. It works that way which leads me to believe my circuit is good but there is something on the configuration which is causing the problem. 

Thanks,

Tuna 

  • Hello Tuna,

    Few initial points to get started on debug here:

    1) Have you made sure all the interrupt enables required are being called including the IntMasterEnable?

    2) Is your device self powered or bus powered? If bus powered, you need to set USBHCD_VBUS_AUTO_HIGH I believe, even with your setup.

    If you want to test on an EK-TM4C123GXL LaunchPad, I can walk you through the hardware adjustments needed, but we don't have a ported example for usb_host_msc for it. You may want to consider porting the DK example to the LaunchPad to make sure the software is indeed setup correctly with known hardware. That would limit the scope of your search to hardware. I would recommend this pretty strongly, let me know if you need the hardware modification list.

    You also may want to look into the possibility of getting a USB analyzer so you can see what, if any, data packets are being exchanged. If there do not seem to be hardware problems, we may need to get to that level of detail to see what is going on here.

    Also from a general system setup with clock speed etc - have you done something basic like blink an LED to verify the clock settings are working correctly and the device is running at the speed you are expecting?

  • Hello Ralph,

    IntMasterEnable call is being made. I also made sure SysTick interrupt is firing to make sure the problem wasn't the system disabling interrupts. 

    The device is bus powered but as I mentioned If I supply the power from my design and jump the data wires DP and DM to the TM4C129 I can get the functional reads which also tells me my connector and traces are working.

    I also checked with a logic analyzer and it seems to be when the device is plugged in both DP and DM become high and there is no activity on the lines so that seems like the chip doesn't sense that there is a device connected. 

    I checked my clock speed with toggling a timer pin with half the clock source and checked with an oscilloscope.

    I will try to change from OTG to HCD as the next step by changing the function call from OTGMain to HTCMain and Changing the interrupt. 

    Thanks,

    Tuna 

  • Hello Tuna,

    Tuna Bicim said:
    The device is bus powered but as I mentioned If I supply the power from my design and jump the data wires DP and DM to the TM4C129 I can get the functional reads which also tells me my connector and traces are working.

    Have you checked that the device is receiving the 5V then? It sounds like the device VBUS is getting 5V even with your settings because of your setup with EPEN, but I thought if you were supplying that as a host from the MCU VBUS pin, then you need a different setting there. I am not as familiar with the setup using EPEN so that could be my misunderstanding though.

    Also RE: OTG that could be a good step if the device is expecting to be in OTG because the way an OTG device indicates presence is different from just a standard USB device, but OTG also would mean your TM4C may be expected to be a device at some point.

    Looking further into options here, I would try using USB0HostIntHandler instead. That would bypass some of the OTG checks from what I am seeing. That could be the missing piece here as to why it is not seeing the device.

  • Hello Ralph,

    What I meant on the VBUS is that EPEN configuration is good which is why my pcb board supplies proper power to the flash drive. 

    Just changing OTGMain call to HCDMain and changing the interrupt didn't fix the issue. 

    I'll go back to the dk-tm4c123 example and start stripping away screen code and integrate my functions after getting reads from the usb stick. 

    Thanks,

    Tuna 

  • Hello Tuna,

    Do you have a DK-TM4C123G or need to run it on the EK-TM4C123GXL?

  • Hello Ralph,

    I do not have the DK board.

    I have 2 EK boards. 

    I started porting the DK board to TM4C123FH6PM and I also can test by jumping the Data pins from the traces on top of the EK board like I did with the EK-TM4C129.

    If that also doesn't work I will post my ported code here to try to get insight. 

    Is there any changes I have to make other than removing the screen and button elements from DK one and changing pins to the pins on the EK or FH6PM board?

    Thanks,

    Tuna  

  • Hello Ralph,

    I ported the code and I am able to run it with EK-TM4C123 when I jump the data pins to my test points on my pcb. The power to the msc is still supplied through the pcb. 

    However, when I try to run the code from TM4C123FH6PM It simply doesn't work. I have 2 of these chips that are isolated on my pcb. One of them has a crystal (25 MHz) and the other one has no crystal. Both were unable to connect to the msc. I did that to test if having no crystal was affecting anything but that seems not to be the issue. Next thing I will try to swap tm4c123fh6pm with gh6pm like the EK board to see if that helps.

    Thanks,

    Tuna 

  • Hello Tuna,

    I'm honestly wondering a bit about the VBUS setup with the example code we provide as I was tinkering on my LaunchPad some and I haven't been able to get it to output VBUS properly on the LaunchPad. Still trying to dig into what is going on there on my end.

  • Hello Ralph,

    I tested jumping from the chip that has the crystal again and I am able to read the flash drive.

    That leads me to believe:

    1) If there is no crystal, usb operation can get affected. 

    2) I just have a bad chip and need to swap it out.

    I will try to swap it next week and if I am still having problems I'll change my layout to have a crystal attached. 

    Best,

    Tuna 

  • To test my theory I removed the crystal from the other chip and tried to jump DP and DM lines.

    It seems not to work. That leads me to believe a crystal is necessary for USB operation.

    Even if the PLL is used to have a higher clock than 20 MHz it is not enough to satisfy the USB conditions.

    Best,

    Tuna 

  • Hello Tuna,

    I shifted from trying to figure out the VBUS issue (because I was trying to get my LaunchPad working without a blue wire mod) to look into the crystal requirements while you were doing your experiments, and I can confirm that the missing crystal is the issue.

    From the device datasheet: Note that the MOSC provides the clock source for the USB PLL and must be connected to a crystal or an oscillator.

    So that is why the internal PLL isn't able to handle this - though when you first mentioned that in your post I didn't think much of it because it was running fast enough.

    The datasheet in Section 24.9.5 Main Oscillator Specifications has Table 24-20 which lists the external crystal frequencies that are supported by MOSC and included in there is which crystals will also support USB. Please reference that for crystal selection for the device.

    Sorry that I didn't catch that right off the bat.