Lauterbach reports MPC5602D is in state: running(reset), what does it mean?

[JohnnyChen]

On customer's Ecu, MPC5602D run into a special state. It seems that Mcu is hanging without functionality. In order to know what happened to Mcu, we connected Lauterbach JTAG debugger to Mcu (RESET pin is disconnected so hot plugin will not trigger unexpected reset assertion over JTAG interface) and try to "attach" to Mcu. However Lauterbach cannot access it and we can see that Lauterbach report "running (reset) " at the right- bottom of status bar. Also we cannot stop Mcu either, always show message: "access timeout, target running".

Do you know what's going on with MPC5602D? What's the status of core at that moment? What kind of issue can take MPC5602D e200z0 core into that stage?

[petervlna]

Hi,

This will block the mode transition -> it means no transition at all.

Micro will stay in its current mode.

Core will not hang during mode transition. ME module will perform mode transition only if all requirements for mode transition are met. Otherwise it is still in current mode.

Is you wake up asynchronous to core execution or micro notify the wake up source that it has already entered LPM state?

Peter

[JohnnyChen]

Hi Peter,

Thanks a lot for your support. I'm checking the timing info while the issue occurs. However it's hard for us to replicate it on EVB.

[petervlna]

Hello,

When Lauterbach reports "running (reset) " this mean that it cannot connect to core.

This is typical for core on low power mode when LPM debug is not ON or for core in halt state. Or when core is held in reset by SW, or HW. Then debugger cannot connect to it.

There are multiple reasons why debugger can display "running (reset) ".

First of all:

Do your system runs after power on reset?

If yes, can you do "halt core on power on reset" via Lauterbach?

Can you step/debug it after power on reset?

Are you providing correct voltages/currents to MCU?

Little information about system would be nice. I like to have overview on the issue fist.

Then I can judge.

Peter

[JohnnyChen]

Hi Peter,

Thanks a lot for your reply!

I got similar info from Lauterbach support team that "reset" means ONCE OSR[core] is held in reset state. "running" means OSR[debug] = 0.

Below please find my comments to your questions:
Do your system runs after power on reset?
>> System can runs after power on reset. This "running(reset)" has very low rate to occur. ??
If yes, can you do "halt core on power on reset" via Lauterbach?
>> Yes, in normal case, T32 works perfectly.
Can you step/debug it after power on reset?
>> Yes.
Are you providing correct voltages/currents to MCU?
>> Yes.

1) This is typical for core on low power mode when LPM debug is not ON or for core in halt state.
>> LPM debug is ON during attach process.
We thought this issue might be relative to standby exit. We have checked the errata(EB770: This includes errata e3570,
e3584, and e3950.), but it’s hard for us to explain why Mcu stays in such condition. We think in customer’s case (LPM mode transition code locates in flash), a Checkstop Reset should recover Mcu back to proper state.

2) Or when core is held in reset by SW, or HW. Then debugger cannot connect to it.
>> What kind of case can hold core in reset? Do you have some comments in detail?

3) Is it possible that Mcu keeps reseting periodic? It will also show "running(reset)".
We confirmed that in software, Mcu SWT(watchdog) is ON always. All Mcu ports seem to be invalid. We checked RESET pin, it keeps high as normal. There is no reset pulse.
We also have set RGM.FBRE NOT to generate an external reset on functional reset.
We suppose maybe Functional Reset has occurred for this case.

‘Functional’ resets:
– external reset
– JTAG initiated reset
– debug control core reset
– software reset
– checkstop reset
– FMPLL fail
– FXOSC frequency lower than reference
– CMU clock frequency higher/lower than reference : 
– 4.5V low-voltage detected
– code or data flash fatal error

There are no detail info in RM for below three Reset types. Do you have more info and is there any way to generate such kind of Resets on EVB? We would like to emulate that on EVB to check the behavior. 
– code or data flash fatal error
– JTAG initiated reset
– debug control core reset

[petervlna]

Hi,

2.) for example SBC chip can hold reset line.

or code can put core into halt mode via halt instruction, etc...

3.) Yes, it is possible. Watchdog will reset micro in loops.

- JTAG initiated reset is external reset cause by debugger

– code or data flash fatal error  - This MCU implements LC flash which is controlled by flash controller. If flash controller fails this flag is set.

-  debug control core reset - this event can only be asserted when the DBCR0[RST] field is set by an external debugger. See the "Debug Support" chapter of the core reference manual for more details. For more details check core reference manual.

Peter

[JohnnyChen]

Hi Peter,

Thanks a lot for your reply. Please see my comments below.

2.) for example SBC chip can hold reset line.

>> Since RESET pin keeps HIGH during such issue, it seems that it's not relative to SBC. 

or code can put core into halt mode via halt instruction, etc...

>> 

3.) Yes, it is possible. Watchdog will reset micro in loops.

>> Watchdog reset is a destructive reset which will always assert RESET pin during the reset phase. So this issue is not triggered by periodic watchdog reset. 

- JTAG initiated reset is external reset cause by debugger

>> No debugger connected while this issue occurred. Lauterbach "attach" command will not reset Mcu.

– code or data flash fatal error  - This MCU implements LC flash which is controlled by flash controller. If flash controller fails this flag is set.

>> Is there any way to generate a flash controller error?

-  debug control core reset - this event can only be asserted when the DBCR0[RST] field is set by an external debugger. See the "Debug Support" chapter of the core reference manual for more details. For more details check core reference manual.

>> No debugger connected while this issue occurred. Lauterbach "attach" command will not reset Mcu.

[petervlna]

Hi,

Flash controller error cannot be forced by external event.

The error must come from flash controller execution itself.

As it is hard to judge where is the issue from your brief description of project an issue, I suggest to call FAE assigned to your company, so he can see the issue exactly on-site.

One more remark:

Did you tied to reproduce this issue on our EVB?

Peter

[JohnnyChen]

Hi Peter,

Thanks for your comment. We have duplicated the issue on standalone Ecu.

We have confirmed that even RGM_FBRE is all set to ‘0’, when MCU is stuck in running(reset) state, reset pin still keeps HIGH without any pulse. It seems that this issue is not caused by Functional Reset.

We also found that the key step to duplicate the issue: is to send CAN msg to wakeup Mcu through CanRx pin while Mcu is entering into STANDBY mode.

Please note: There is only one wakeup source for system. CAN module has already been disabled(FREZ=HALT=1) before performing below function.

Detail steps for key function to trigger issue:  

 1) Prepare to enter LPM(STANDBY) mode.
       a. Clear existing WISR[CanRxd] wakeup Flag.
      b. MSR[ME]=1; MSR[EE]=0; CPR.B.BPI = 0; PSR[CanRxd]=0; IRER[CanRxd] = 1; WRER[CanRxd] =1; WIFEER[CanRxd]=1

2) Entering into LPM Standby mode via MCAL API: Mcu_SetMode(). Please note LPM transition code is running at Flash.

3) If failed to enter into STANDBY mode, goto Step1.

We found if set IRER[CanRxd] =  0 during step(1.b), it seems that Mcu can works fine without entering into “Running(rest)”. If set IRER[CanRxd] =  1, then we has high rate to encounter the issue.

Now customer has tested periodic wakeup and periodic sleep with more Ecu boards, for one day and night. Ecu with IRER[CanRxd] =  0  works fine.

We noticed that there is a errata e7953. It's too roughly that we can't get any detail info from it. It seems that this is the root cause. We think this errata also apply to STANDBY mode, right? But how to understand "block the mode transition" or "possibly lead to unspecified behavior."?  Does it mean: 1) mode transition fail and return to previous mode; 2) core hanging during mode transition; 3) mode transition fail and always stay in transition state flow? 

e7953: ME: All peripherals that will be disabled in the target mode must have their
interrupt flags cleared prior to target mode entry
Description: Before entering the target mode, software must ensure that all interrupt flags are cleared for
those peripheral that are programmed to be disabled in the target mode. A pending interrupt
from these peripherals at target mode entry will block the mode transition or possibly lead to
unspecified behavior.
Workaround: For those peripherals that are to be disabled in the target mode the user has 2 options:
1. Mask those peripheral interrupts and clear the peripheral interrupt flags prior to the target
mode request.
2. Through the target mode request ensure that all those peripheral interrupts can be serviced
by the core.

Johnny