2383517_en-US

[#1]

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