When enter VLPS, system reset

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

When enter VLPS, system reset

2,777 Views
huisheng_huang
Contributor III

Hi,

I am facing a tough issue, and have been working on it for a week. But issue not solved yet. so come here for some help.

I am using s32k148, and MCAL (S32K14X_MCAL4_3_RTM_HF2_1_0_1). The issue is when i call function Mcu_SetMode() to enter VLPS, system will reset, with the reset reason SACKERR. 

I have call Os_DisableInterruptSource()(Autosar interface) to disable all the interrupt source but except the PTE5 interrupt which is connected to Rx pin of CAN0.

Reset is occured after execute EXCUTE_WAIT.

asdf.png

0 Kudos
Reply
8 Replies

2,758 Views
huisheng_huang
Contributor III

Thank you, Daniel.

Yes, you are great. When I disable the CAN module, no reset  happens. 

But after that, I have another problem.

MCU can't be waked up by a external interrupt, which is PORTE, pin 5.

Before enter VLPS, I enable the interrupt.

asdf.png

When in debugger mode, I checked the PCR register, as below, the ISF is set.

asdfdsf6-11.png

My question is, why didn't enter the ISR and wake up the MCU?

Thank you in advance.

0 Kudos
Reply

2,755 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Have you tested the interrupt in the RUN mode?

Does it work?

Do you use Sleep-Now or Sleep-On-Exit mode?

Because in the Sleep-on-exit mode, the MCU goes back to VLPS immediately once the ISR is complete.

So you might not notice the ISR was executed.

 

BR, Daniel

0 Kudos
Reply

2,751 Views
huisheng_huang
Contributor III

Yes, it works in RUN mode.

We don't use the sleep on exit mode. as below:

Snipsdafsdf38.png

A strange phenomenon is when in debugger mode, after the external interrupt occurs, MCU didn't enter ISR. But if i pause the debug session , MCU enters the ISR.

sdfasdfte_2020-11-02_18-32-27.png

0 Kudos
Reply

2,739 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi,

It looks like an issue of the tool not the MCU.

Please try running the MCU stand-alone without the debugger.

I mean, disconnect the debugger, power cycle the MCU and toggle a GPIO (for example) from the ISR.

Also, you can output BUS_CLK on a CLKOUT pin so that you can see when the MCU is VLPS and when it is running.

 

BR, Daniel

 

0 Kudos
Reply

2,723 Views
huisheng_huang
Contributor III

Hi Daniel,

Maybe I know the reason.

After below modification, all is normal.

huisheng_huang_0-1604379924033.png

Before the code EXECUTE_WAIT, SW call DisableAllInterrupts(). So I think we should use the corresponding call function EnableAllInterrupt(). If so, then we should modify the MCAL code. I don't know whether ok or not?

0 Kudos
Reply

2,713 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi,

In the newest MCAL4.2 1.0.4 release, the EXECUTE_WAIT macro contains only the WFI instruction.

Both SuspendAllInterrupts() and ResumeAllInterrupts() have been removed and you can removed it as well.

But anyway, the interrupts must not be disabled/masked (PRIMASK) at the time the WFI instruction is executed, you need to enable them.

 

Regards,

Daniel

 

0 Kudos
Reply

2,727 Views
huisheng_huang
Contributor III

Hi Daniel,

I have tried your suggestion.

I disconnect the debugger, power off the board and power on again. when MCU enters to VLPS, trigger an  interrupt, but no changes on the GPIO. Besides, the current I measured doesn't change.

I have output the BUS_CLK to the CLKOUT pin. At run mode, the frequency is 2.5MHZ. When enters to VLPS, the CLKOUT is a high level.

So, I think the MCU is not able to be waked up.

 

0 Kudos
Reply

2,761 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi,

Can you please disable the FlexCAN module before the transition to VLPS?

FlexCAN is not supported in VLPS and should be disabled.


Thank you,

BR, Daniel