mm9z1-638 low power mode issue:COP and API still run during stop mode

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

mm9z1-638 low power mode issue:COP and API still run during stop mode

1,886件の閲覧回数
gumu
Contributor V

Dear Sir,

Recently, I have beeing doing sleep/wakeup stress tests for our project.There is an issue about watchdog timeout issue that will reset the device.

Here is my experimental environment:

1.monitoring eclipsed time for every task,(5ms task, 100ms task, 1000ms task)

2.make system enter stop mode  every 5s in 1000ms task, wakeup device in 5s with rtc

3. use a CAN frame to send the max eclipsed time of task

4. 4 DUT

testing data:

gumu_0-1691654007902.png

 

extern void ApiTask1000ms(void)
{
	static u32 cnt1000ms = 0;
	u32 thres = 60000;
	u32 end_time = 0;
	u32 start_time = 0;

	start_time =  u32SysRunTick;
	cnt1000ms++;
	if (cnt1000ms % 5 == 0)
	{
		cnt1000ms = 0;
		ApiPowerEnterStopMode(thres);
	}
	end_time = u32SysRunTick;
	if ((end_time - start_time) > u16Task1000msConsumed)
	{
		u16Task1000msConsumed = end_time - start_time;
	}
}

 

datasheet says:

COP and API should be disabled in stop mode. Under normal conditions, COP and API were indeed disabled for device 4 and 3, abnormal conditions, COP and API still run.  COP will reset device because I have enabled COP.

I'd like to know what factors are influencing to stop the COP.

Thanks!

タグ(1)
0 件の賞賛
返信
7 返答(返信)

1,788件の閲覧回数
Q_man
NXP Employee
NXP Employee

Hi Mu,

I still do not understand your setup.

Which clock source is used by the COP? Which configuration do you use?

Q_man_0-1692252973995.png

Could you also share the ApiPowerEnterStopMode(thres)?

 

0 件の賞賛
返信

1,769件の閲覧回数
gumu
Contributor V

Hi @Q_man ,

I checked the relative registers. The current configuration is Static (IRCCLK), 

gumu_0-1692324710560.png

extern void ApiPowerEnterStopMode(u32 current_ah_thres)
{
	u8 CAN_status[3];
	u16 timeout = 10000;

	CAN_STDBY(STANDBYMODE);
        DelayMs();
	Sleep_CAN(CAN0, CMPTX);                           // request CAN channel 0 go to sleep with completing transmission scheduled
	do {
		Check_CAN_Status(CAN0, CAN_status);          				  // read the channel 0 status
	} while (!(CAN_status[1] & SLPAK) && timeout--);				  // wait till SLPAK bit set

	B_PCR_WUEH_WUPTB4 = 1; // enable PTB4 wakeup
	
	ApiIoCtrl(GPIO_P_PLUS_SWT, FALSE);               

	B_GPIO_TSENSE = 0;
	B_GPIO_VSENSE = 0;
	ADCDisable();
	TsenseDisable();

	ApiRtcSetWakeupPeriod(wakeup_timeout);
	CurrentWakeupCfg(current_ah_thres);
	PCREnterStopMode();
	ApiPowerRecoverFromStop();
	// .....zzzzzzzzzzz (stop mode)
	// after wakeup the code continues to run here....
	// but first the D2D Interrupt service routine will be run
	B_WD_CTL = WD_OFF;
	VsenseInit();
	CsenseInit();
	TsenseInit();
	ADCInit();
	ApiCanIfRestRxMbSts();
	Wakeup_CAN(0);
	CAN_STDBY(NORMALMODE);
}
0 件の賞賛
返信

1,755件の閲覧回数
Q_man
NXP Employee
NXP Employee

Hi Mu,

the original issue of having a COP reset must be linked to not entering (immediate wakeup) stop mode then! As discussed a wakeup after timeout should be implemented with the TIM module on the analog chip, as the uC can not wakeup the analog die. The D2D supply (VDDH) is 0V when the analog die is in low power mode!

0 件の賞賛
返信

1,814件の閲覧回数
Q_man
NXP Employee
NXP Employee

Hi Mu,

I"m not sure if I fully understand your setup, but it seems you are using the device in a not common way.

To optimize low power consumption the analog die is fully controlling the wakeup from system stop and sleep modes. There is no mechanism that the uC can wakeup the analog die / system! Doing so, might lead to strange effects, typically triggering a low voltage reset, as the current capability of the Vreg (VDDX = 5V) is limited to ~3mA in stop (analog die) mode.

To self wakeup the device after time a timer (TIM16B4C) has to be used, which is located and clocked on the analog die.

Q_man_0-1692181567150.png

 

W.

0 件の賞賛
返信

1,808件の閲覧回数
gumu
Contributor V

Hi @Q_man ,

Agreed with what you said. In my experiment, the microcontroller is responsible for calling the device's sleep function every 5 seconds, and then it is awakened by the LFT after 5 seconds, and this process repeats in a loop. When this probabilistic issue occurs, the RTI clock and COP are still operational. Otherwise, there should not be a delay of several seconds from sleep to awakening. As shown in my screenshot, the 1000ms task took a long time to complete.

0 件の賞賛
返信

1,875件の閲覧回数
gumu
Contributor V

Dear Sir,

Please let me add, this issue is very low probability, it only happens once every few hours.

There is a section in the datasheet 6.2.1.8.4:

 

The clock source for the COP is either ACLK, IRCCLK or OSCCLK depending on the setting of the COPOSCSEL0 and COPOSCSEL1 bit. 
Due to clock domain crossing synchronization there is a latency time to enter and exit Stop mode if the COP clock source is ACLK and 
this clock is stopped in Stop mode. This maximum total latency time is 4 ACLK cycles (2 ACLK cycles for Stop mode entry and exit each) 
which must be added to the Stop mode recovery time tSTP_REC from exit of current Stop mode to entry of next Stop mode. This latency 
time occurs no matter which Stop mode (Full, Pseudo) is currently exited or entered next. 
After exit from Stop mode (Pseudo, Full) for this latency time of 2 ACLK cycles no Stop mode request (STOP instruction) should be 
generated to make sure the COP counter can increment at each Stop mode exit.

 

 Do I need add some delay function?

 

void PCREnterStopMode(void)  {	

  IrqDisable();     
  B_INT_MSK = 0xFF3F;       // disable all Analog Interrupts 
  B_ACQ_SRH = 0xFF;        // Clear pending Flags
  B_INT_MSK = 0xFF00;     // enable all Analog Interrupts 
  
  B_PCR_SR =  0xFFFF;  	// Clear Flags
  B_PCR_CTL = OPM_SET_STOP;   // Goto Stop Mode
///add delay???
  StopEnable();		
  StopEnter();
}

 

 

 

タグ(1)
0 件の賞賛
返信

1,834件の閲覧回数
TomasVaverka
NXP TechSupport
NXP TechSupport

Dear Mu, 

I would like just to inform you that our MM9Z1_638 expert is currently out of the office, but should be back in the second half of this week. So please expect some delay in his response.

Best regards,

Tomas

0 件の賞賛
返信