pin reset after execution of "WFI" instruction

[hajianik]

Hi,

Target is S32K148.

I'm able to enter VLPS mode successfully however AS SOONAS the "WFI" is executed I get a pin reset.

all the wake up sources are disabled at this time , so there shouldn't be any wake up and the module should stay in VLPS mode unless waken up by a wake up source.

When I fire up my debugger and place a break point on WFI , it hits it and then if I run it , it stays in VLPS without any issues.

I even tried to insert some NOPs before and after the WFI but I still get a PIN RESET.

Any clues?

Thanks,

Koorosh Hajiani

[danielmartynek]

Hi Koorosh,

Do you read the RCM_SRS register after reset?

Is it really the PIN reset source?

Because this indicates an external reset.

Thank you,

BR, Daniel

[hajianik]

Hi Daniel,

yes, I do read it and it says PIN reset(external) as the source of the reset, I also verified it on the Scope.

Do You think it is a hardware issue?

I don't believe it is a hardware issue.

As I mentioned before a break point on "WFI" hits and then if I SAY GO , it stays in SLEEP , then I can wake it up by sending a specific CAN frame.

I inserted delay loops before and after "WFI" but it does not help.

Thanks,

Koorosh Hajiani

[danielmartynek]

Hi Koorosh Hajiani,

The PIN flag should be set only if the reset source is external.

Anyway, the FlexCAN module is not supported in VLPS.

It should be disabled before the MCU enters VLPS.

Can you disable the module?

Also, in debug mode, the MCU enters an emulated stop mode instead of VLPS.

Please try running the board stand alone and measure the consumption or BUS_CLK on an CLKOUT pin.

Thank you,

BR, Daniel

[hajianik]

Hi Daniel,

Thank you for your response,

Actually the way it wakes up is via CAN transceiver's can_rx pin which is configured as a pin interrupt( just before entering sleep).

the external tool sends a CAN frame which wakes up the CAN transceiver and the can_rx pin makes a transition which results in a pin interrupt and wakes the micro up.This part works as I designed to work

I've run this stand alone and reset is there and  I can observe the current drawn  on an ammeter , it drops to what is supposed to in sleep for a short period of time, less than a second because we enter the VLPS mode and suddenly there's the reset and module wake back up again and with no CAN  it just keeps resetting and waking. exactly same behaviors the debugger.The only difference is that current is a bit higher with debugger running.

does Placing break point places the Micro in some kind of the wait state?

if true  what kind of a wait state is that.?

Regards,

Koorosh Hajiani

[danielmartynek]

Hi Koorosh,

Can you elaborate on this:

"... it drops to what is supposed to in sleep for a short period of time, less than a second because we enter the VLPS mode and suddenly there's the reset"

What do you mean by the sleep mode? Is it VLPS?

If so, the MCU can enter VLPS and stay there for less than 1s and so there is no problem with the transition.

The RCM_SRS register provides the source of the most recent reset - this is the purpose of it and if it says PIN reset then it should be an external reset.

How do you read the register when the MCU runs stand-alone, do you send it out via LPUART, for example?

Because the debugger can reset the MCU with PIN reset afterwards.

Regards,

Daniel

[hajianik]

Hi Daniel,

thanks for your reply,

You quoted:

"... it drops to what is supposed to in sleep for a short period of time, less than a second because we enter the VLPS mode and suddenly there's the reset"

I may misstate that, here is what happens we enter the VLPS mode successfully,that is why the current drops and then I EXECUTE "WFI" WHICH CAUSES THE RESET.

my impression is when you execute WFI it should stays in VLPS mode until and unless a configured wake up source wakes it up, as soon as wfi is executed it generates a reset where the module is back to awake and on the debugger I read a PIN reset. I don't have  uart  code to print out to a terminal.so when I run it stand alone I can't read RCM_SRS, but I can see the external reset pin transition from hi to lo on the logic analyzer.

also you wrote:

"Because the debugger can reset the MCU with PIN reset afterwards"

It could but why ?

I have used this debugger with other codes that puts the module in VLPS mode and it just says HALT, until I wake it up with a pin interrupt.So I don't believe is the debugger but it may very well be, the debugger just execute the "wfi" that's where the reset happens , stand alone or the debugger the reset happens'. Please look at page2 of the attached file, that shows it runs go to sleep and reset asserted and cycle repeats.

Thanks,

Koorosh

[danielmartynek]

Hi Koorosh,

I'm sorry but there are a few things that very confusing in the description.

1. The MCU enters VLPS by executing the WFI instruction. And once it is in VLPS, the core cannot execute another WFI instruction as the core clock is gated off and the system is Waiting For an Interrupt.

2. Each of the RCM_SRS reset sources causes the reset_b pin to go from HIGH to LOW. So, in order to determine the source of the reset, the RCM_SRS register must be read.

What I meant was that when the MCU runs stand alone, the reset source is unknown, and then the debugger can reset the MCU through PIN reset when the debugger gets connected which would over-write the RCM_SRS register to PIN reset.

If the MCU resets itself, the first step is to read the RCM_SRS register at the beginnig of the application code, it can be stored into EEPROM or print out when the MCU is running stand-alone.

Have you tried disabling all the interrupt (mask them) before the MCU enters VLPS?

Regards,

Daniel