UE910-EUD USB linux turn-on problem

10 thoughts on “UE910-EUD USB linux turn-on problem

  1. UE910-EUD is connected to UART and to USB of Atmel SAM9x25. The power of  UE910-EUD is 3.6V and is always on. 

    After I pull ON_OFF pin low the kernel(3.10) says:

    [ 1155.281000] usb 1-1: new high-speed USB device number 3 using atmel-ehci
    [ 1155.398000] usb 1-1: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
    [ 1155.399000] usb 1-1: New USB device found, idVendor=058b, idProduct=0041
    [ 1155.400000] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    [ 1155.406000] cdc_acm 1-1:1.0: This device cannot do calls on its own. It is not a modem.
    [ 1155.411000] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
    [ 1204.174000] usb 1-1: USB disconnect, device number 3
    [ 1204.385000] usb 1-1: new high-speed USB device number 4 using atmel-ehci
    [ 1219.488000] usb 1-1: device descriptor read/64, error -110
    [ 1234.692000] usb 1-1: device descriptor read/64, error -110
    [ 1234.896000] usb 1-1: new high-speed USB device number 5 using atmel-ehci
    [ 1249.999000] usb 1-1: device descriptor read/64, error -110
    [ 1254.235000] usb 2-1: new full-speed USB device number 4 using at91_ohci
    [ 1269.394000] usb 2-1: device descriptor read/64, error -110
    [ 1284.653000] usb 2-1: device descriptor read/64, error -110
    [ 1284.912000] usb 2-1: new full-speed USB device number 5 using at91_ohci
    [ 1300.070000] usb 2-1: device descriptor read/64, error -110
    [ 1315.330000] usb 2-1: device descriptor read/64, error -110
    [ 1315.589000] usb 2-1: new full-speed USB device number 6 using at91_ohci
    [ 1325.993000] usb 2-1: device not accepting address 6, error -110
    [ 1326.152000] usb 2-1: new full-speed USB device number 7 using at91_ohci
    [ 1336.555000] usb 2-1: device not accepting address 7, error -110
    [ 1336.556000] hub 2-0:1.0: unable to enumerate USB device on port 1

    Apparently, the bootloader (vid=058b, pid=0041) is confused and waiting about 50 seconds prior to start the Telit FW. Finally  UE910-EUD failes to start. UART keeps silence too. What could it be?? 

  2. it seems your host USB is full-speed.

    Normal
    0

    14

    false
    false
    false

    IT
    X-NONE
    X-NONE

    MicrosoftInternetExplorer4

     

    Full speed is ok for AT commands i.e. only when the module is fully operative.

    The bootloader only supports USB HS. When the module is turned one, it presents to the host a flashing port.
    This flashing ports, that is used to update the fw, waits for some inputs.
    If
    the input arrives the flashing procedure is started, otherwise the
    module continue normally its boot and finally presents the typical 7
    ports.

     

    On Win CE for example the module takes 50 secs to turn on. There could be different behaviors depending on the Host driver implementation. On Windows the port couln’t be recognized.

     

    What we suggest is to connect/supply the USB, 5 seconds after the ON/OFF pulse.

     

    1. These lines prove that host is high-speed:

       

      [ 1155.281000] usb 1-1: new high-speed USB device number 3 using atmel-ehci

      [ 1155.411000] cdc_acm 1-1:1.0: ttyACM0: USB ACM device

       

      The bootloader is successfully enumerated, but for some reason cannot continue normally its boot to finally present the typical 7 ports.

      1. You are right, also I didn’t notice the UART port is not working too, so we have to understand if there is any problem during the ON procedure:

         

        1) Is the ON_OFF line toggled for at least 5 seconds?

        2) Can you check if the PWRMON pin remains high after the module is turned on?

        3) What is the firmware version of the module?

         

         

        1. Andrea,

            1) The ON_OFF line goes low and remains there.

            2) The PWRMON  remains high after the module is turned on

            3) The firmware version is 12.00.xx4

             At the beginning the module worked fine, but under some circumstances it has fallen in this strange state. What was done was a periodic turn-on/turn-off procedure with ON_OFF and SHUTDOWN pins.

           With HE910 we were able to get out of this case by reflashing the firmware.

           Today we got the same case with UL865 fw 12.00.605. The same  turn-on/turn-off
           cycling with voltage supply ON/OFF. Currently we are not able to completely remove voltage from the module. It still remains at 0.6-0.8 V level due to some schematic issues.

           

          1. ok so I think we already received the same request from Alexander Chernov.

            The analysis of my collegue was the following:

             

            You procedure was:

            ################################################################

            In a test involving only two pins: HW_SHUTDOWN (R13) and ON_OFF (R12). 3.6V power to the module is always on.

            Cycle:

                 1. HW_SHUTDOWN – low, ON_OFF – high

                 2. Pause 300 ms

                 3. HW_SHUTDOWN – high, ON_OFF – high

                 4. Pause 300 ms

                 5. HW_SHUTDOWN – high, ON_OFF – low

                 6. Pause 4000 ms

             ################################################################

             

            This ON / OFF procedure is wrong and should be avoided, but in our test it still does not kill the module.

            I
            was unable to reproduce this issue. I have made a test automation with a
            script, exactly reproducing your scenario. After 50 cycles, the module
            can still be turned on and is working normally.
            The test was HW_SHUTDOWN button pressed for 300ms.
            300 ms of pause and then ON_OFF button pressed for 4000ms. Then 300ms pause  and then repeat.

            The MINIMAL time that the ON_OFF signal should stay low is 5000ms! 4000ms is 1000ms less.
            When
            this 5000ms have passed, the module starts the "power on" process,
            which takes about 1000ms. Only then the module is operational.
            They should not turn off the module during this "power on" process. 

            The second problem, as described in the Hardware user guide is:

            "
            … HW_SHUTDOWN* …

            WARNING:
                  The hardware unconditional Shutdown must not be used during normal operation of the device 
                  since it does not detach the device from the network. It shall be kept as an emergency exit 
                  procedure.

            "
            A wrong ON / OFF procedure may damage the module. 

             

             

             

          2. Hi Andrea,

             

              Nonetheless, I know two different boards that have succeeded in killing the module. It seems like something happened with main firmware. One board was able to resurrect its module by the reflashing process.

              Is there any way to find out the fail cause or the state the module is in?? Say, some debug information during booting, states of pads or whatever…  

            A wrong ON / OFF procedure may damage the module. 

              Curious and both dramatic issue. The user just drives the ON_OFF pin and the module might be damaged. I could understand if the user supplied 5V instead of 4.2V and module was killed. But just driving a pin improperly.. During development process the improper on/off sequence is almost inevitable…

          3. hi, there are no debug info stored during booting , if there is a hardware damage. It’s necessary to be compliant to hw specs. the only thing that we can do is to try to reproduce at our side the exact sequence the user did to see if it happens also at my side, or you need to contact Teit directly to send your damaged sample with the hope to detect the cause (without guarantee of finding it, if the module has not been correctly managed)

  3. Hi,

     

    We too have destroyed an HE910 and an LE910 module simply by use of an incorrect ON_OFF assertion time. Is there any advice on how to prevent this, particularly in automotive environments where the power supply is very unstable during ignition.

     

    Regards

     

     

    Tim Clacy