# Qcpwrdn shut down issue on WP7603 **URL:** \ **Category:** mangOH Red\ **Created:** [November 5, 2018, 7:38pm UTC](https://mangoh.discourse.group/t/qcpwrdn-shut-down-issue-on-wp7603/2075 "2018-11-05T19:38:37Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ktanikel](https://avatars.discourse-cdn.com/v4/letter/k/bcef8e/32.png) [@ktanikel](https://mangoh.discourse.group/u/ktanikel)\ **Post date:** [November 5, 2018, 7:38pm UTC](https://mangoh.discourse.group/t/qcpwrdn-shut-down-issue-on-wp7603/2075/1 "2018-11-05T19:38:37Z")
Hi, We’re seeing an issue on our mangOH Red units that shutdown for unexplained reasons. Here is a crash log we were able to extract. ``` Nov 5 17:31:31 swi-mdm9x28 user.warn kernel: [61.011285] irq 50, desc: cefdb000, depth: 0, count: 0, unhandled: 0 Nov 5 17:31:31 swi-mdm9x28 user.warn kernel: [61.011308] ->handle_irq(): c025ac68, msm_gpio_irq_handler+0x0/0x150 Nov 5 17:31:31 swi-mdm9x28 user.warn kernel: [61.011338] ->irq_data.chip(): c0ed8e68, gic_chip+0x0/0x74 Nov 5 17:31:31 swi-mdm9x28 user.warn kernel: [61.011361] ->action(): (null) Nov 5 17:31:31 swi-mdm9x28 user.warn kernel: [61.011372] IRQ_NOPROBE set Nov 5 17:31:31 swi-mdm9x28 user.warn kernel: [61.011383] IRQ_NOREQUEST set Nov 5 17:31:31 swi-mdm9x28 user.warn kernel: [61.011394] IRQ_NOTHREAD set Nov 5 17:31:32 swi-mdm9x28 user.info kernel: [62.443635] gpio_check_and_wake: wake-n_gpio26 STATE=WAKEUP Nov 5 17:31:32 swi-mdm9x28 user.info kernel: [62.465129] gpio_check_and_wake: wake-n_gpio26 STATE=SLEEP Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: qmi_at_unsol_ind_cb: ind id:33 Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: Received AT command forward request from modem Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: fwdcmd.opcode=1 Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: fwdcmd.name=$QCPWRDN Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: fwdcmd.ntokens=0 Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: ctrCond signalling complete. Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: Recieved ctrCond: p: 0, S:0, nr: 1 Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: QCPWRDN has been detected Nov 5 17:31:33 swi-mdm9x28 user.warn kernel: [63.685455] PSM: Modem oprt mode - 3 Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: sending QMI_AT_FWD_RESP_AT_CMD_RESP_V01 message Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: qmi_client_send_raw_msg_sync returned: 0 Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: New request processing complete. Nov 5 17:31:33 swi-mdm9x28 user.info swiapp: Waiting for ctrCond Nov 5 17:31:33 swi-mdm9x28 daemon.info init: starting pid 1755, tty '': '/etc/init.d/rcK' Nov 5 17:31:33 swi-mdm9x28 user.info kernel: [63.872044] gpio_check_and_wake: wake-n_gpio26 STATE=WAKEUP Nov 5 17:31:33 swi-mdm9x28 user.info kernel: [63.879719] swimcu_device_init: start 0x7ff Nov 5 17:31:33 swi-mdm9x28 user.info kernel: [63.883297] swimcu_device_init: mcufw ver=2.009 target=1 opt=0xF Nov 5 17:31:33 swi-mdm9x28 user.info kernel: [63.887979] swimcu_device_init: success Nov 5 17:31:33 swi-mdm9x28 user.info kernel: [63.895223] swimcu_set_fault_mask: 0x100, cnt 1 Nov 5 17:31:33 swi-mdm9x28 user.info kernel: [63.895241] swimcu reset_recovery: complete Nov 5 17:31:33 swi-mdm9x28 user.info kernel: [63.895250] swimcu_set_reset_source: 0x40 Nov 5 17:31:33 swi-mdm9x28 user.info kernel: [63.895271] gpio_check_and_wake: wake-n_gpio26 STATE=SLEEP ``` Does anyone know what QCPWRDN means, and why it would cause a random shutdown? cm info details: ``` root@swi-mdm9x28:~# cm info Device: WP7603-1 IMEI: 351711090107910 IMEISV: 4 FSN: WD752585161410 Firmware Version: SWI9X07Y_02.16.02.00 000000 jenkins 2018/04/19 19:59:02 Bootloader Version: SWI9X07Y_02.16.02.00 000000 jenkins 2018/04/19 19:59:02 MCU Version: 002.009 PRI Part Number (PN): 9907595 PRI Revision: 001.004 Carrier PRI Name: GENERIC Carrier PRI Revision: 002.032_000 SKU: 1103727 Last Reset Cause: Power Down Resets Count: Expected: 248 Unexpected: 2 ``` Legato version ``` root@swi-mdm9x28:~# legato version 18.06.1_302932300e810a4fb0cba7b4960af4fd ``` ---
**Author:** ![rkirk](https://avatars.discourse-cdn.com/v4/letter/r/da6949/32.png) [@rkirk](https://mangoh.discourse.group/u/rkirk)\ **Post date:** [November 7, 2018, 6:51pm UTC](https://mangoh.discourse.group/t/qcpwrdn-shut-down-issue-on-wp7603/2075/2 "2018-11-07T18:51:28Z")
Hi @ktanikel, As you’ve identified, the source of the shutdown is the $QCPWRDN command which coordinates the system power down routine. This isn’t something I’ve seen before, without a trigger, so to understand your platform a bit better: 1. Do you have any custom applications? If you have any custom apps that are triggering Ultra-Low power mode or PSM, those could be the triggers for the coordinated shutdown behaviour. 2. Is the timing consistent? Log shows ~60 seconds - is this always true? 3. Is there a USB host connection? If so, can you disconnect that and use only the UART console to communicate with the device temporarily? In that configuration, is the power down still occurring (i.e. removing any host-supplied commands to determine if the origin is host or on-target). Those are the first things that come to mind. Ryan ---
**Author:** ![ktanikel](https://avatars.discourse-cdn.com/v4/letter/k/bcef8e/32.png) [@ktanikel](https://mangoh.discourse.group/u/ktanikel)\ **Post date:** [November 7, 2018, 8:02pm UTC](https://mangoh.discourse.group/t/qcpwrdn-shut-down-issue-on-wp7603/2075/3 "2018-11-07T20:02:03Z")
Thank you for your reply Ryan. To address your questions 1. Yes, we have a custom application that uses ULPM. We set GPIO36 and a timer as boot sources before entering ULPM. However, the problem reported here seems to occur outside of our custom application control i.e. something else is initiating the shutdown and we’re trying to understand what that could be. Here’s what the log looks like when our applications triggers low power mode. As you can see, the boot sources are being set and log clearly indicates it is going in to a LPM state. Also, there seems to some difference with respect to “Modem oprt mode” going to -3 in the problem condition vs -1 in the normal operation. I don’t know what the significance of that is. 1. I don’t have enough information on this yet. We’ve only been able to capture the log once which is what you see above. I’ll update as we got more data. 2. There is no USB host connection. The device is running on an internal battery and is also connected to an external power supply. We haven’t yet found the exact conditions to reproduce this problem. However, we have several devices out in production that are exhibiting this behavior so we’re trying to address this as best we can with the information at hand. ---
**Author:** ![ajoseph](https://avatars.discourse-cdn.com/v4/letter/a/8797f3/32.png) [@ajoseph](https://mangoh.discourse.group/u/ajoseph)\ **Post date:** [November 13, 2018, 7:30pm UTC](https://mangoh.discourse.group/t/qcpwrdn-shut-down-issue-on-wp7603/2075/4 "2018-11-13T19:30:10Z")
Hi @ktanikel Do you have "“logread -f” for the shutdown scenario? The logs could help identify the trigger for the shutdown. ---
**Author:** ![ktanikel](https://avatars.discourse-cdn.com/v4/letter/k/bcef8e/32.png) [@ktanikel](https://mangoh.discourse.group/u/ktanikel)\ **Post date:** [November 14, 2018, 5:41pm UTC](https://mangoh.discourse.group/t/qcpwrdn-shut-down-issue-on-wp7603/2075/5 "2018-11-14T17:41:05Z")
Hi @ajoseph We don’t have the output of "logread -f " because we’ve never encountered this problem during development or testing with the USB connected. The problem seems to occur when the unit is operating off a battery and the only logs we can get are /mnt/flash/legato\_logs/, which is what I’ve posted here. As per my understanding, ‘logread’ gets written to legato\_logs when there is crash, so what you’re seeing here is essentially logread. ---
**Author:** ![ajoseph](https://avatars.discourse-cdn.com/v4/letter/a/8797f3/32.png) [@ajoseph](https://mangoh.discourse.group/u/ajoseph)\ **Post date:** [November 14, 2018, 7:24pm UTC](https://mangoh.discourse.group/t/qcpwrdn-shut-down-issue-on-wp7603/2075/6 "2018-11-14T19:24:33Z")
This scenario looks like an organized shutdown. The “$QCPWRDN” is the final command which actually shutdown the modem, but the trigger itself is somewhere else. Legato logs leading up to “$QCPWRDN” being called may provide an idea as to what the trigger is. Logs for the app is stored in case of an application crash at /mnt/flash/legato\_logs/. [https://docs.legato.io/latest/c\_logging.html#c\_log\_debugFiles](https://docs.legato.io/latest/c_logging.html#c_log_debugFiles). To ensure Legato logs are captured(which should show the trigger), you will have to redirect “logread -f” to a file (by running script at startup) or modifying syslogd to store logs to a fie. ---
**Author:** ![liamodonnell](https://avatars.discourse-cdn.com/v4/letter/l/e480ec/32.png) [@liamodonnell](https://mangoh.discourse.group/u/liamodonnell)\ **Post date:** [July 19, 2022, 8:48am UTC](https://mangoh.discourse.group/t/qcpwrdn-shut-down-issue-on-wp7603/2075/7 "2022-07-19T08:48:30Z")
Hello @ktanikel, Did you ever resolve this issue? I’ve just started seeing this issue today, and was fortunate enough to grab logread -f. ```auto Jul 19 08:20:45 swi-mdm9x28-wp user.info kernel: [4060.782706] gpio_check_and_wake: wake-n_gpio26 STATE=SLEEP Jul 19 08:20:45 swi-mdm9x28-wp user.info Legato: INFO | core[894]/coreComponent T=main | Core.cpp Button2Callback() 59 | Button 2 Released (HIGH). Jul 19 08:20:46 swi-mdm9x28-wp user.info kernel: [4061.135092] gpio_check_and_wake: wake-n_gpio26 STATE=WAKEUP Jul 19 08:20:46 swi-mdm9x28-wp user.info kernel: [4061.145137] swimcu_device_init: start 0xfff Jul 19 08:20:46 swi-mdm9x28-wp user.info kernel: [4061.145157] swimcu_device_init: start 0xfff Jul 19 08:20:46 swi-mdm9x28-wp user.info kernel: [4061.149619] swimcu_device_init: mcufw ver=2.011 target=1 opt=0xF Jul 19 08:20:46 swi-mdm9x28-wp user.info kernel: [4061.158717] swimcu_device_init: device init success Jul 19 08:20:46 swi-mdm9x28-wp user.info kernel: [4061.158745] swimcu_gpio_refresh Jul 19 08:20:46 swi-mdm9x28-wp user.info Legato: INFO | dcsDaemon[875]/dcsCellular T=main | dcsCellular.c DcsCellularConnEventStateHandler() 257 | State of connection 1 transitioned from up to down Jul 19 08:20:46 swi-mdm9x28-wp user.info Legato: INFO | modem[897]/modemComponent T=main | Modem.cpp ConnectionStateHandler() 262 | Interface: . Jul 19 08:20:46 swi-mdm9x28-wp user.info kernel: [4061.212147] swimcu_set_fault_mask: 0x100, cnt 1 Jul 19 08:20:46 swi-mdm9x28-wp user.info kernel: [4061.212170] swimcu_reset_recovery: swimcu_reset_recovery complete Jul 19 08:20:46 swi-mdm9x28-wp user.info kernel: [4061.212184] swimcu_set_reset_source: 0x40 Jul 19 08:20:46 swi-mdm9x28-wp user.info kernel: [4061.212210] gpio_check_and_wake: wake-n_gpio26 STATE=SLEEP Jul 19 08:20:46 swi-mdm9x28-wp user.err Legato: =ERR= | modemDaemon[880]/le_pa T=main | pa_mrc_qmi.c pa_mrc_GetCurrentNetwork() 2921 | Cannot retrieve current Network information. Jul 19 08:20:46 swi-mdm9x28-wp user.info Legato: INFO | modem[897]/modemComponent T=main | Modem.cpp ConnectionStateHandler() 284 | Data state is disconnected. Jul 19 08:20:46 swi-mdm9x28-wp user.info swiapp: qmi_at_unsol_ind_cb: ind id:33 Jul 19 08:20:46 swi-mdm9x28-wp user.info swiapp: Received AT command forward request from modem Jul 19 08:20:46 swi-mdm9x28-wp user.info swiapp: fwdcmd.opcode=1 Jul 19 08:20:46 swi-mdm9x28-wp user.info swiapp: fwdcmd.name=$QCPWRDN Jul 19 08:20:46 swi-mdm9x28-wp user.info swiapp: fwdcmd.ntokens=0 Jul 19 08:20:46 swi-mdm9x28-wp user.info swiapp: ctrCond signalling complete. Jul 19 08:20:46 swi-mdm9x28-wp user.info swiapp: Recieved ctrCond: p: 0, S:0, nr: 1 Jul 19 08:20:46 swi-mdm9x28-wp user.info swiapp: QCPWRDN has been detected Jul 19 08:20:46 swi-mdm9x28-wp user.warn kernel: [4061.259674] PSM: Modem oprt mode - 3 ``` I do not use ulpm, so unless one of the built in applications is sending my device to sleep, I am not sure what is causing this to happen.