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.

LM4F132H5QD fail to detect host connection for usb

Hi,

I'm working on a custom board using controller LM4F132H5QD with usb connected as device for CDC mode.

Once i plug in the usb cable to my host pc, i can see my board in device manager.

On removing the cable, the device is removed from the list. But when i try to connect USB cable 2nd time, I cannot see the device in the list. Also no disconnect event interrupt generated when disconnected the first time.

On every boot the same scenerio is repeated.

I checked the voltage on USBVBUS. It is 4.97v in all case when connected and 0 when disconnected.

Can anyone point to the possible reason for such behaviour.

Thanks....

  • This could happen if you are forcing device mode in your application.  Can you post your USB library configuration code that you are using in the application?

  • Hi Paul,

    Yes we are forcing it in device mode. Also we observed that the behaviour is strange as somtimes it detects the usb host and somtimes it keeps failing and recovers only on reboot.

    Also we tried the same on another board, there also the behaviour is same and also the controller is getting heated up on inserting usb cable. Once cable is removed, the temperature lowers down.

    I'm attaching a basic code for usb CDC device, which i checked on the board.

    8535.usb_dev_serial.rar

  • In the code you sent, you are not actually forcing it to device mode so you should get the disconnect event.    

    You are making the following call that does set the mode to device mode, but the controller will still pay attention to the state of the VBUS and ID input pins.  These must be connected directly to the USB connector for everything to work correctly.  Can you verify the USB_O_DEVCTL(0x40050060) register when connected and disconnected? 

  • Hi Paul,

    Following is the value for USB_O_DEVCTL 

                                 On boot, USB disconnected , 0x00

                                 On USB cable connected , 0x99 (remains same for rest of its time)

    Value for USB_VBUS, when connected 5.04

                                            when disconnected 2.24

    In debugger mode, i found that no disconnect event occurred on disconnecting the cable so the comport always remains occupied all the time from board end.

  • VBUS holding at 2.24V is your problem with disconnect.  The voltage must drop below around 0.7V to actually see the disconnect event.  Does it actually hold at 2.24V or is it actually a slow decay?  If you want to see if this is the problem remove the conditional setting of the internal pull down on PB1 and always enable the pull down.

    Unconditionally call to test if the VBUS holding at 2.2V is your problem.

    HWREG(GPIO_PORTB_BASE + GPIO_O_PDR) |= GPIO_PIN_1;

  • Hi Paul,

    I made the change in the code, making the line internally pull down. Now the VBUS voltage on disconnect changed to 1.63v, while on connection it remains at 5.02v.

    Though i still do not see the DISCONNECT EVENT occurring in my debugger mode, my device manager list is updated each time.

    As my VBUS line in directly connected to the usb connector, from where i'm seeing this spurious value?

  • That is strange, the voltage should not hold there.

    You are saying that the VBUS pin goes directly to the device and no where else on the board?  Have you seen this on more than one board setup?

    Also just so that we know what device you have, what is the revision of your device?

    The value at SYSCTL_HWREV(0x400FEF68) will tell you the revision.

  • Hi Paul, 

    I know the behaviour is strange.

    My SYSCTL_DID0 shows me 0x18050101 and  SYSCTL_HWREV(0x400FEF68)  is 0x10070101.

    Another thing to be noticed is that i checked the sample usb_dev_serial on eval kit LM4F232H5QD. This board shows the same behaviour as my board. Here also the board misses the USB_DISCONNECT_EVENT. So the behaviour can be easily verified there.

  • Sorry for the delay.  I tried this on the LM4F232H5QD board with TivaWare 1.1 and I do get the disconnect event.  The version of the LM4F device on that board does require the pull down to bring vbus down after a disconnect event.

    Did you put the conditional in as well as the write?

    //
    // Erratum workaround for silicon revision A1. VBUS must have pull-down.
    //
    if(CLASS_IS_BLIZZARD && REVISION_IS_A1)
    {
        HWREG(GPIO_PORTB_BASE + GPIO_O_PDR) |= GPIO_PIN_1;
    }

    or just 

        HWREG(GPIO_PORTB_BASE + GPIO_O_PDR) |= GPIO_PIN_1;

  • Hi Paul, 

    It is really strange that you are not able to see the same behavior on your end as it is reproduced every time on my board.

    On my eval board the sample code has the conditional statement and i can see in the debugger that every time the pin is pull down but no disconnect event.

    Similar is the behavior on our custom board. There i have forced the statement (removed the if statement) and every time the pin is pulled down, still do not see that disconnect event.

    Can there be any possibility of any errata in the controller.

    Please suggest how can we work out this condition as we are ready with the product(other than the USB) and soon can plan for a production, if the issue gets resolved. So i have lot of pressure to work out the problem.

  • I am testing using the TivaWare 1.1 release for this board and not seeing any issue with receiving disconnect.  

    What version of TivaWare are you using on the LM4F232H5QD board?

    That pull down enable is specifically to deal with an erratum on early revision A1 devices that were shipped on the LM4F232H5QD boards.  It did have to do with VBUS not falling all the way to 0V causing disconnect to not occur.  This was fixed in the production parts and VBUS should properly decay to 0V and cause the disconnect event to occur.  The disconnect event is triggered by VBUS dropping below around 0.7V so if you are seeing it stay above that value then the disconnect event does not occur.  

  • Hi Paul,

    As far i understood from your post, u are saying that earlier there was an issue in the micro controller which was resolved in the production. So can we please verify that whether we have the right release of controller or not. Please mention what all information u need to verify the controller release so that we can draw any conclusion about the issue. If the issue is because of an old release of controller, then we can look to verify the issue with the new release of micro controller.

  • Based on the values you posted for DID0 above you have the production devices which do not have an issue with the VBUS pin. 

    I do still need to know what version of TivaWare you are using to be sure that this is not a software problem.

  • Hi Paul,

    The EVM we are using belongs to Rev A0.

    So it will show the issue as per your words.

    But why we are seeing the same issue on our board as i mentioned i checked it on two boards with the same output.

    So kindly guide the way out. This way we are not able to proceed with any further work on this.

    Mention if any more input can lead to a conclusion.

  • To truly duplicate what you are seeing on the evaluation board, I will need to know the software release that you are using.

  • Hi Paul,

    I don't know which software release, i mean how to get it. I had sent you the sample code i was trying. Also if i had done the initialization properly i should not be able to see any voltage on my VBUS line once disconnected.  Can u please verify if all is done properly in the software initialization, may be some difference in the way USB initialized at my end, leading to the issue as u are not seeing the same at your end.

  • I believe Paul is asking you what version of TivaWare you are using. version 1.0 or 1.1. You can get version 1.1. from here - http://www.ti.com/tool/sw-tm4c  - You will need either Complete or perhaps just the USB Library. 

    Included with TivaWare are bunch of USB libraries, which can be found in the following directory once TivaWare is installed  c:\ti\TivaWare_C_Series-1.1\usblib\

    Unless you wrote your own  libraries from scratch...which I doubt very much!

    You will also need, if you don't already have it, the TivaWare USB Library User Guide - http://www.ti.com/litv/pdf/spmu297 

    MCU Heating Up Issue - you mentioned that the MCU heats up when you insert the USB cable. I have also experienced this problem on the Tiva LaunchPad. The conditions to make this happen seem to be when I am debugging, so have a USB cable in the ICDI USB port and the Power Select Switch is set to it. I then insert a USB cable into the USB Device/Host connector which also provides power. The MCU then heats up....thought I fried it, but still working. I cannot remember if this was on the board which I have turned into a USB host by populating R25 and R29 or the board which is in default config as a USB device (I was debugging the usb_dev_serial example). I have not had the problem since I have shifted the Power Select Switch to receive power from the USB Device/Host connector and not the ICDI connector.

  • Yes I was looking for the TivaWare version to see if I could duplicate the problem here.  The version is in the header of every source file that we ship.  You should see something like "This is part of revision 1.1 of the EK-LM4F232 Firmware Package."

  • Hi Paul,

    Earlier i was using the older set of codes stating "revision 8555"

    Today i downloaded the latest code set with "This is part of revision 1.1 of the EK-LM4F232 Firmware Package", 

    but for me the outcome was same. Still no disconnect event generated.

  • Hi Paul,

    Glad to tell that the issue is solved now. Thanks to the TI team here.

    The issue was with the ESD protection IC -TPD2S017 that latched the voltage to 2.2v.

    As the IC was connected on D+ and D- , we were doubting it to the least.

    Once VCC line was removed from that IC, we got the USB part properly working.

    Thanks again....

  • Glad to hear that was resolved and thanks for the wrap up post.