Reset not working, AEP totally blocked

Home › Forums › Conduit: AEP Model › Reset not working, AEP totally blocked

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • December 26, 2016 at 7:21 pm #16139
    Capecchi Olivier
    Participant

    Hello,
    I have the following problem : I tried to include a script to start the Loriot binary at each Conduit reboot but it seems to have totally stuck the Conduit. Ok, whatever, I decided to reset to factory defauts by pressing the Reset button but nothing happens !!!! Absolutely nothing, the conduit is not reseting and I cannot access it through SSH and it’s not bootin (STATUS led not blinking) !
    Anybody has an idea of the problem or the way to solve it ?
    Anybody had problems with the reset button not working ?
    Thanks in advance for the help, Happy New Year to all
    Lucas

    December 27, 2016 at 9:16 am #16144
    Peter Ferland
    Blocked

    Hi Lucas,
    To reset the Conduit to factory defaults you need to hold in the reset button for a full 30s. After the 30s you will see the LEDs flash. Can you confirm that the reset switch was depressed for this long?

    In addition to SSH, there are two micro USB ports that can be used to access a terminal. The port on the front of the Conduit behind a removable panel (one screw) provides debug access including the ability to enter u-boot. More detail on this debug port can be found here: http://www.multitech.net/developer/software/mlinux/using-mlinux/mlinux-configure-and-use-hardware-io/
    Can you connect to the serial debug port and access the system from there?

    December 29, 2016 at 2:35 am #16161
    Capecchi Olivier
    Participant

    Hi Peter,
    I finally manage to reset the Conduit using the Debug port and some precious help from the Multitech support guys (thanks guys !).
    But I’m a bit disappointed about the reset button that is not working at all (and seems that I’m not the only one to have faced this issue).
    Anyhow, lesson learned !
    Cheers,
    Lucas

    January 1, 2017 at 6:50 am #16180
    JJ Deng
    Participant

    Dear all,
    i got the same issue here.
    Can anyone share the information, how to reset it?
    30S button reset didn’t work at all.

    January 1, 2017 at 7:18 am #16181
    JJ Deng
    Participant

    Whatever i try, there is no response of input via micro usb debug port on the front plate.

    January 2, 2017 at 3:19 am #16184
    Capecchi Olivier
    Participant

    Hello Deng,
    Could you give a full description of what you tried ? I had some difficulties in using the debug port too but at the end I managed it so if you describe me your trials I will perhaps be able to help you a bit.
    Cheers,
    Lucas

    January 4, 2017 at 12:17 pm #16208
    Rob Spurrett
    Participant

    I had the same problem. For some reason, if I press the reset button three times for about ten seconds, and on the last press, hold it in until it reboots, then it works. I have no idea why and it does this consistently. All undocumented.
    PS And by the way, if you do a reset, you’ll wipe out the NodeRED flow application and have to re-install it from deviceHQ.

    January 4, 2017 at 4:16 pm #16210
    Jeff Hatch
    Keymaster

    All,

    I looked at the code that handles the reset button press. It is handled in the mts-io kernel module and by the reset-monitor process. The kernel module keeps track of a short press (~5s), a long press (> ~5s && <= ~30s), and an extra long press (> ~30s).

    On AEP, for a short press a SIGHUP is sent to the reset-monitor. For a long press a SIGUSR1 is sent to the rest-monitor. For an extra long press a SIGUSR2 is sent to the reset monitor. These are not the hard-coded defaults, but are set on boot by On the AEP Conduit the reset monitor process is the watchdog process. The following is what happens for each button press length:

    short press (< ~5s): the system just reboots long press (> ~5s && < ~30s): the device is reset to user defined defaults and rebooted. The factory settings are used if user defined defaults have not been set. extra long press (> ~30s): the device is reset to factory defaults.

    I believe that the status LED should go solid at the start of reboot until the kernel is back up and the mts-io module is reloaded, then the status LED should start blinking normally again, but don’t quote me on that as I have not dug into that functionality to verify that.

    I have not observed any behavior outside these parameters on my device, however it is only one device, and the hardware is almost a year old.

    I am interested what the load is on these devices that are exhibiting this bad behavior on reset. If you have time to gather some information and let me know here or file a support portal ticket at https://support.multitech.com, please let me know. If you can provide the following information:

    1) Output of a top command to see what the CPU and memory state of the system is.
    2) A ‘cat’ of /sys/devices/platform/mts-io/reset-monitor.
    3) A ‘cat’ of /sys/devices/platform/mts-io/reset-monitor-intervals

    That would be a start to figure some of these issues out. If #’s 1, 2, and 3 look OK, maybe it is an actual bad hardware problem.

    Thank You,

    Jeff

    January 4, 2017 at 4:22 pm #16211
    Jeff Hatch
    Keymaster

    Ack, second paragraph of previous entry should say:

    On AEP, for a short press a SIGHUP is sent to the reset-monitor. For a long press a SIGUSR1 is sent to the rest-monitor. For an extra long press a SIGUSR2 is sent to the reset monitor. These are not the hard-coded defaults, but are set on boot by the AEP watchdog process. On the AEP Conduit the reset monitor process is the watchdog process. The following is what happens for each button press length:

    Jeff

    January 28, 2017 at 7:09 am #16545
    Kamran Alam
    Participant

    AEP module is totally blocked. Cant access it nor reset it.

    Please help. Need to reset the conduit.
    @Capecchi Olivier, can you please tell the suggestion by the support guys.

    Regards
    Kamran

    January 30, 2017 at 9:12 am #16553
    Jeff Hatch
    Keymaster

    Kamran,

    When you say you can’t access the device, do you mean that you cannot access it through the debug console? If you have hooked up a USB cable to the debug console, is it stuck at the the point where all it says is “ROM boot”?

    Jeff

    February 3, 2017 at 5:01 am #16652
    Alexandros Rapsomanikis
    Participant

    Same thing happened to me. Instructions about how to recover your conduit have been addressed in previous comments, so I’d like to address the fact you wanted to include a script to start the LOR IOT binary.

    I tried to include a script to start the Loriot binary at each Conduit reboot but it seems to have totally stuck the Conduit.

    1. Create file /etc/init.d/start-loriot.sh
    2. In here, put
    #! /bin/bash
    cd /home/root/ && ./loriot_multitech_conduit_mCard_USB_1.0.1
    (or wherever you put the binary)
    ○ It’s important to cd into the folder first, otherwise LORIOT cannot find the certificate.
    3. chmod +x /etc/init.d/start-loriot.sh
    4. Link the script: ln -s /etc/init.d/start-loriot.sh /etc/rc5.d/S99start-loriot.sh
    Now reboot, should start up automatically.

    I hope this helped.

    Source from Githbub

  • Author
    Posts
Viewing 12 posts - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.