T1024 RESET_REQ without any cause registered Hi, there are some months we have a problem with T1024 CPU. Thank you in advance. PROBLEM DESCRIPTION: We use T1024NSE7KQA CPU inside our industrial PLC. Until last year were using MQX OS (single-core implementation), then we had it ported to a dual-core Linux implementation using SDKLINUX (the OS has been mostly implemented by a third-party). The HW is physically the same of the previous MQX OS version. All units show a problem during Linux startup: the MCU get stuck (the MCU itself asserts RESET_REQ_B). The event is not deterministic: only 10% of startup cycles are affected but it happens always in the same OS startup phase. We replicated the problem with a periodic startup/power down sequence. If the event appears after powerup, it happens always ~40 s after HW startup/initialization and 5-8 s after the OS startup has completed (the time from the startup to the event slightly changes due to a slight variability in the OS process schedule). Otherwise, the event won’t show up again and we need to wait for some power cycles for it to happen. The RCW is correct and the PBL phase completes correctly. With oscilloscope we checked the O1VDD, OVDD, G1VDD, VDD, VDDC rail voltage before the event but they are stable and inside CPU tolerances. During the event we measured a RESET_REQ_B:H->L transition. We interrupted any on-board connection from RESET_REQ_B to onboard circuitry (so that RESET_REQ_B does not force a transition of HRESET_B nor PORESET_B) in order to read the DCFG_CCSR_RSTRQSR1 register in the same startup cycle or in the following one but it results to be always 0x0 value. We are sure that CPU is internally requesting the reset but we cannot find its reason. We set the max verbosity to the OS log but just before the event during a problematic startup we cannot see nothing different (compared to a startup without the issue): no kernel messages, no process message, no exceptions, … We are logging periodically the DCFG_CCSR_RSTRQSR1 register via UART: after the event the CPU cannot write anything more. We tried to mask all reset causes (set to 1 all non-reserved bit of DCFG_CCSR_RSTRQMR1) but the issue keeps happening. QUESTIONS: • Are there any RESET_REQ_B causes not mapped to DCFG_CCSR_RSTRQSR1? I remind that we masked all non-reserved bits in DCFG_CCSR_RSTRQMR1 but without luck; • How could we dig down to understand which CPU mechanism requested the RESET_REQ_B? • Could the CPU enter in a low consumption Power management state and therefore assert the RESET_REQ_B ? Thank you for clarification, Giacomo Gasparini. Re: T1024 RESET_REQ without any cause registered by the way I cannot access to my official account: which is your reference mail to support these type of issues? thank you Re: T1024 RESET_REQ without any cause registered Hello,
For your three questions:
1) Are there any RESET_REQ_B causes not mapped to DCFG_CCSR_RSTRQSR1 ? Yes: CPU/core watchdog timer reset-request causes are not mapped in RSTRQSR1 ; they are captured in DCFG_CCSR_RSTRQWDTSR when configured for watchdog reset request mode. The T1024 RM explicitly says RSTRQSR1 excludes core watchdog timer sources, and RSTRQWDTSR is the dedicated watchdog status register. For the documented non-watchdog causes, RSTRQSR1 includes at least: IFC_RR , WDT_RR (summary indicating at least one watchdog bit is set in RSTRQWDTSR ), SW_RR , CCM_RR , PBL_RR , SFP_RR , SEC_RR , SDC_RR , MBEE_RR , RPTOE_RR , and SRDS_RST_RR .
2) How can you dig down further? The most useful next step is to capture a broader reset snapshot in the same failing boot cycle, not just RSTRQSR1 . In a prior T1024 support case, the recommended register set was: DCFG_CCSR_RSTCR , DCFG_CCSR_RSTRQPBLSR , DCFG_CCSR_RSTRQMR1 , DCFG_CCSR_RSTRQSR1 , DCFG_CCSR_RSTRQWDTMR , and DCFG_CCSR_RSTRQWDTSR . Given your symptom timing—Linux fully boots, then the fault occurs about 5–8 s later—the likely fields to pay attention to are:
RSTRQWDTSR for per-thread watchdog expiration detail
RSTRQSR1[SW_RR] in case software is writing DCFG_CCSR_RSTCR[RESET_REQ] (bit 30) directly or through some reset path
RSTRQSR1[RPTOE_RR] for an RCPM timeout reset request event associated with core halt/stop/reset request handling
RSTRQSR1[MBEE_RR] for platform internal memory multi-bit ECC
RSTRQSR1[SRDS_RST_RR] for enabled SerDes PLL not locking
A few source-grounded debugging observations:
RESET_REQ_B may assert at any time , and once asserted it stays asserted until PORESET_B is asserted.
The design checklist recommends keeping an option to disconnect RESET_REQ_B from PORESET_B or HRESET_B specifically for debug/RCW override scenarios, because otherwise recurring reset loops prevent diagnosis.
NXP support guidance in similar cases says a CPLD is generally not a practical logger of RSTRQSR1 after a catastrophic internal event ; a debugger reading the reset registers with minimal SoC involvement is considered more practical.
So, with the documentation I found, the most direct debug approach is:
Keep RESET_REQ_B from causing an immediate POR path during debug.
Capture both RSTRQSR1 and RSTRQWDTSR , plus RSTCR , RSTRQPBLSR , and the mask registers.
If possible, halt with JTAG immediately after RESET_REQ_B asserts but before any external reset propagates.
3) Could the CPU enter a low-power state and therefore assert RESET_REQ_B ? For the standard T1024 power-management states—PH10/doze, PH15/nap, LPM20/sleep—the retrieved T1024 documentation does not describe entry into those states as a cause of RESET_REQ_B . Those modes are entered through RCPM control and exited by wakeup events, interrupts, hard reset, or other documented wake mechanisms. Deep sleep is different: on deep sleep wakeup , the EPU finite-state machine explicitly requests a warm device reset during exit ( Exit.2: XTRIG[9]: Request warm device reset ). Also, the white paper’s Linux suspend/deep-sleep flow says the EPU issues a device warm reset as part of deep-sleep wakeup before boot code resumes. However, that is a deep-sleep restore mechanism , not a normal consequence of entering PH10/PH15/LPM20 during ordinary runtime.
regards Re: T1024 RESET_REQ without any cause registered First of all, thank you for the detailed and quick reply! 1) Basing on your reply we tried to mask also the watchdog reset causes with DCFG_CCSR_RSTRQWDTSR register value 0x3 but the issue remains. 2) We were able to read the registers via JTAG using the CodeWarrior TAP. Just after the event we gave the “Suspend” command and read the following register values: It seems that the cause is a Software reset (DCFG_CCSR_RSTRQSR1[SW_RR]=1). It is coherent with the fact that this cause of RESET_REQ_B is not maskable via the DCFG_CCSR_RSTRQMR1 register; here’s why the issue is keeping showing up.... We are investigating about this reset cause. 3) in my original question the cause and effect were reversed: may the CPU enter into a low-power state and THEN causing a RESET_REQ_B assertion? If you could help, at the end I'm adding a related question about a connection issue from CPU to JTAG TAP during the CPU register read trials we did today: After giving the Suspend command to CodeWarrior with the CodeWarrior TAP connected to the CPU, only 1 time we could read the CPU registers; every other times we tried we saw this error (see photo) and we lost connection with CPU. Is it a CodeWarrior configuration issue? How could we solve it? Thank you again. Giacomo.
View full article
