JN5189 and MMAC, takes much time to vMMAC_Enable()

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

JN5189 and MMAC, takes much time to vMMAC_Enable()

ソリューションへジャンプ
18,517件の閲覧回数
usaygo
Contributor III

Hello support,

I tried using MMAC with JN5189 (SDK2_6_10) and found that with my sample code, the vMMAC_Enable() procedure call takes 80ms (just to check with the WTIMER count). This is especially problematic for applications that perform sleep/wakeup.

I would like to know if this is anomaly or not. Any ideas?

1 解決策
17,857件の閲覧回数
Kaasboer
Contributor I

Make sure you use the function call vRadio_Temp_Update(int16_t s16Temp); where s16Temp is the current temperature in half degrees Celcius (2's complement). So use s16Temp = 40 for 20 degrees Celcius.

To have the value stored permanently, use bRadioCB_WriteNVM() and u16RadioCB_ReadNVM(), after defining gRadioUsePdm_d.

元の投稿で解決策を見る

0 件の賞賛
返信
18 返答(返信)
17,858件の閲覧回数
Kaasboer
Contributor I

Make sure you use the function call vRadio_Temp_Update(int16_t s16Temp); where s16Temp is the current temperature in half degrees Celcius (2's complement). So use s16Temp = 40 for 20 degrees Celcius.

To have the value stored permanently, use bRadioCB_WriteNVM() and u16RadioCB_ReadNVM(), after defining gRadioUsePdm_d.

0 件の賞賛
返信
17,840件の閲覧回数
usaygo
Contributor III

Hello Kaaboer,

vRadio_Temp_Update() works very fine. I tried inserting before the first MAC initalization or restoring MAC API, both worked fine. 

For just experimet, I set an extreme value like 20degC -> -20degC, which affects execution time of MAC initialization. With small change in temperature, MAC initialization takes very short. With a big change, it may take longer.

Generally, it seems that it could be constant value like 20*2. I finally use on-chip TEMP sensor and set with its value.

Thanks!

0 件の賞賛
返信
18,474件の閲覧回数
EduardoZamora
NXP TechSupport
NXP TechSupport

Hello @usaygo,

I apologize for the late response.

Could you please provide more details about the timer you are using? How are you setting/configuring this timer?

What is the procedure you are using to measure this time/interval? Which events are you using to trigger the measure?

Regards,
Eduardo.

0 件の賞賛
返信
18,468件の閲覧回数
usaygo
Contributor III

Hi Eduardo,

Thanks for updating

We should focus on execution time of the function vMMAC_Enable().  My first question is it's anormal or not.

How are you setting/configuring this timer? What is the procedure you are using to measure this time/interval? Which events are you using to trigger the measure?

Problem is NOT timer use. I double check with GPIO control and see with oscilloscope. (note: VCC level is 0V)

PXL_20230403_224826897.jpg

Here is the abbreviated code.

#include "fsl_gpio.h"
#define DGC_PORT 19 // DIP PIN#27.
void DGC_Init() {
	// set the pin as input
	gpio_pin_config_t gpio_conf = { kGPIO_DigitalOutput, 1 /* 1 to HIGH */ };
	GPIO_PinInit(GPIO, 0, DGC_PORT, &gpio_conf);
}
static inline void __DGC_SetHi() { GPIO_PortSet(GPIO, 0, 1u << DGC_PORT); }
static inline void __DGC_SetLo() { GPIO_PortClear(GPIO, 0, 1u << DGC_PORT); }

int main(void) {
  SYSCON->CODESECURITYPROT = 0x87654320;
  BOARD_InitBootPins(); // configure IOCON->PIO[], customed
  BOARD_BootClockRUN(); // clock configure (Xtal32M is enabeled later)
                        // set CPU clock as 32MHz

  GPIO_PortInit(GPIO, 0);
  DGC_Init();
  __DGC_SetLo(); // SET GPIO PORT
  vMMAC_Enable(); // THIS TAKES APPROX. 80ms
  __DGC_SetHi(); // SET GPIO PORT
  CLOCK_EnableClock(kCLOCK_Xtal32M); // can move to BOARD_BootClockRUN() when  cold booting.
  CLOCK_AttachClk(kXTAL32M_DIV2_to_ZIGBEE_CLK); // can move to BOARD_BootClockRUN() when  cold booting.

 ...
}

void WarmMain() {
  SYSCON->CODESECURITYPROT = 0x87654320;
  BOARD_InitBootPins(); // configure IOCON->PIO[], customed
  BOARD_BootClockRUN(); // clock configure (Xtal32M is enabeled later)
                        // set CPU clock as 32MHz

  __DGC_SetLo(); // SET GPIO PORT
  vMMAC_Enable(); // THIS TAKES APPROX. 80ms
  __DGC_SetHi(); // SET GPIO PORT
  CLOCK_EnableClock(kCLOCK_Xtal32M); // MUST PLACE HERE, OTHERWISE HUNGs
  CLOCK_AttachClk(kXTAL32M_DIV2_to_ZIGBEE_CLK);
  ...
}

 

> Could you please provide more details about the timer you are using? 

  • It happens both Cold Starting and Warm Starting.
  • WTIMER counter can be used split time measurement (it is very accurate by confirming with oscilloscope.)
  • project was made from the project template. 
    • set "__mac_buffer_base = 0x04000000;" in ld file, which required by MiniMac.
  • I tried another MiniMac lib (2.6.3, MiniMac_??.a ), but all the same.
  • I tried 48MHz CPU clock, no significant change (slightly getting faster).

 

Thank!

0 件の賞賛
返信
18,445件の閲覧回数
EduardoZamora
NXP TechSupport
NXP TechSupport

Hi,

I really appreciate the details.

Just to confirm, which template/example project are you using as base for your development?

I will check on this issue. Please, give me some time, as soon as I have some information to share, I will reply to you.

Regards,
Eduardo.

0 件の賞賛
返信
18,401件の閲覧回数
usaygo
Contributor III

Just to confirm, which template/example project are you using as base for your development?

Both are from SDK2_6_10 sample code and I tried to minimize the modification.

  • ledblinky --> call vMMAC_Enable() on coldboot, check with PIO.
  • powerdown_demo --> call vMMAC_Enalbe() both on coldboot and warm boot, check with WTIMER count at warmboot.

 

image.png

0 件の賞賛
返信
18,413件の閲覧回数
usaygo
Contributor III

Another example from "Power API demo v1.0" with sleep and wakeup.

It still take 80ms approx even waking after the sleep.

//Seigo

UART messages:

Power API demo V1.0
Use power measurement view in MCUXpresso
Reset Cause :    POWER DOWN MODE
SystemCoreClock=12000000
Select Mode
0 - PM_POWER_DOWN
1 - PM_DEEP_DOWN
Powerdown mode PM_POWER_DOWN selected
Select wakeup source
0 - WAKEUP_TIMER_0
1 - WAKEUP_TIMER_1
2 - WAKEUP_DIO
3 - WAKEUP_NONE
Wakeup source WAKEUP_TIMER_0 selected
Input sleep time in seconds
3 seconds sleeping chosen
Press any key to sleep
Sleeping...

--- Warm Boot ---
JOB IN AppInit():(fffff5b8-ffffffcf = 2583ct)
HALT HERE!

 

WarmMain()

/* On Warm Start (memory held), WarmMain() function is called instead of main() */
void WarmMain(void)
{
	// AppInit(); // run the following procedure instead of AppInit()
	{
		BOARD_InitBoard();

		/* Configure the optimized active voltages, set up the BODs */
		// POWER_Init();

		/* Enable LEDs. */
		GPIO_PinInit(GPIO, LED_PORT_0, LED_PIN_0, &((const gpio_pin_config_t){kGPIO_DigitalOutput, 0}));
		GPIO_PinInit(GPIO, LED_PORT_1, LED_PIN_1, &((const gpio_pin_config_t){kGPIO_DigitalOutput, 0}));

		checkIrqPending();

		// if (checkIrqPending()) PRINTF("No IRQ pending\r\n");

		// Assuming WTIMER0 is running.
		u32wt_ct0 = WTIMER_ReadTimer(WTIMER_TIMER0_ID); // store TIMER ID's
		//{ volatile int i = 100000; while(i--) __NOP(); } // approx 1600counts
		vMMAC_Enable();
		u32wt_ct1 = WTIMER_ReadTimer(WTIMER_TIMER0_ID); // store TIMER ID's

		PRINTF("\r\n--- Warm Boot ---");
		PRINTF("\r\nJOB IN AppInit():(%x-%x = %dct)", u32wt_ct1, u32wt_ct0, u32wt_ct1 - u32wt_ct0);

		/* stop timers in case some were running and the wakeup source is something else (case of Multiple wakeup source)
		 * Need to be done after IRQ checking */
		stop_timers();
	}

    //AppMain(); // no AppMain() again.

	PRINTF("\r\nHALT HERE!");
    while(1) __NOP();
}

 

0 件の賞賛
返信
18,423件の閲覧回数
usaygo
Contributor III

Hello,

I made a quick sample from "SDK Samples -> demo_apps -> led_blinky". It still take 77ms with with the simple sample (not tested at warmboot).

My requirement is as below:

  • RAM ON sleep with around 1uA consumption.
  • MAC initialize on wakeup should be minimized. (77ms is too long and drains battery life..., it should be 1 to 2ms like as JN516x)

Thanks!

18,339件の閲覧回数
EduardoZamora
NXP TechSupport
NXP TechSupport

Hi,

I truly apologize for my late response.

The time that this procedure is taking may be due to RF calibration when vMMAC_Enable is called. To try to avoid recalibration, you can configure the device sleep with radio retention:

PWR_ChangeDeepSleepMode(PWR_E_SLEEP_OSCON_RAMON)

PWR_Init()

PWR_vForceRadioRetention(TRUE)

and manage temperature update in application

#define RADIO_TEMP_UPDATE TRUE

Please, refer to JN-AN-1245, RAMOPT=0 build option for these implementations. Please consult JN-AN-1245 > Doc > JN-AN-1245-Release-Notes for more details on SDK compatibility.

I appreciate your patience.

Regards,
Eduardo.

0 件の賞賛
返信
18,331件の閲覧回数
usaygo
Contributor III

Hi Eduardo,

Thanks for the update. It's not successful using MMAC.

By seeing PWR component source, it just put the option PM_CFG_RADIO_RET and finally call POWER_GoToPowerDown() to enter power down state.

I am still struggling with handling the MMAC API before and after sleep. I just tried some, but not successed so far.

/// MMAC INITALIZATION ON COLD BOOT
vMMAC_Enable();
vMMAC_ConfigureRadio();
// no further code here (e.g. send a packet)

/// MMAC before sleeping
vMMAC_RadioToOffAndWait(); // turn off the radio
// vMMAC_Disable(); // should be disabled?

/// ENTER POWER DOWN!
config.pm_config |= PM_CFG_RADIO_RET; // SET RADIO RETINTION
//config.pm_config |= PM_CFG_RADIO_RET | PM_CFG_XTAL32M_AUTOSTART; // need X32M autostart?
ret = POWER_EnterPowerMode(mode, &config);

//////////////////////////////////////////
/// MMAC on wake up
//////////////////////////////////////////
/// case.1
vMMAC_Enable(); // Enabling MMAC (HUNG UP here)

/// case.2
// vMMAC_Enable(); // skip enabling
vMMAC_ConfigureRadio(); // STILL HUNG UP

/// case.3
// vMMAC_Enable(); // skip enabling
// vMMAC_ConfigureRadio(); // skip this
vMMAC_SetChannel(11); // STILL HUNG UP

 

Any suggestion? 

0 件の賞賛
返信
18,306件の閲覧回数
EduardoZamora
NXP TechSupport
NXP TechSupport

Hi,

Could you please test your application skipping/removing vMMAC_RadioToOffAndWait() function and considering the suggestions from my previous reply?

Regards,
Eduardo.

0 件の賞賛
返信
18,265件の閲覧回数
usaygo
Contributor III

Unfortunately, the following aproach did not work.

before sleeping,
  * vMMAC_Disalbe() // I wonder this would close RADIO...???
  * go POWER DOWN (with RADIO RETENTION and AUTOSTART 32M XTAL)
after waking,
  * // skip vMMAC_Enable();
  * vMMAC_ConfigureRadio(); // passes
  * vMMAC_SetChannel(11); // hungs here

 

Any regular and working procedure using MMAC before and after sleeping? It could be code snipet.

The AN-1245 sample uses standard MAC library. Not using MMAC.

0 件の賞賛
返信
18,246件の閲覧回数
EduardoZamora
NXP TechSupport
NXP TechSupport

Hi,

Just to confirm, what is the source you are using as reference for these APIs? What is the reason you are implementing vMMAC_Disable()? Could you please try removing it?

Please, refer to JN5189 SDK docs folder > docs > wireless > Zigbee JN-UG-3134-Zigbee3-Green-Power Chapter 3 MicroMAC Stack for Green Power for more information on initialization.

#define RADIO_TEMP_UPDATE TRUE should enable Radio Setting saving into PDM.

Please try the functions:

PWR_ChangeDeepSleepMode(PWR_E_SLEEP_OSCON_RAMON)
PWR_Init()
PWR_vForceRadioRetention(TRUE)

or an equivalent for radio retention, PWR library should be in charge of disabling/turning off modules and functions that are not necessary in low power.

Regards,
Eduardo.

0 件の賞賛
返信
18,239件の閲覧回数
usaygo
Contributor III

Hello,

Thanks for the update.

> Please, refer to JN5189 SDK docs folder > docs > wireless > Zigbee JN-UG-3134-Zigbee3-Green-Power Chapter 3 MicroMAC Stack for Green Power for more information on initialization.

I checked many times for getting information about MMAC. This document does not say how it should be when sleeping or waking up. No proper function is found to call before sleeping. (only found turn of radio or disabling MMAC). I also check MMAC.h definitions.

 

Just to confirm, what is the source you are using as reference for these APIs?

Simply, I'm just starting MMAC.h with no higher level libraries. (as attached source code) If you don't recommend using MMAC, I need to switch standard MAC. Please give me a suggestion.

> What is the reason you are implementing vMMAC_Disable()? Could you please try removing it?

I tried tons of patterns of removing/adding API calles. As long as my trials, vMMAC_Disable() must be called before sleep, and then vMMAC_Enalbe() is called after wakeup, where taking 80ms. Otherwise, MMAC API call hungs. (adding RADIO RETENTION flag before sleep)

 

> #define RADIO_TEMP_UPDATE TRUE should enable Radio Setting saving into PDM.

> PWR_ChangeDeepSleepMode(PWR_E_SLEEP_OSCON_RAMON)
> PWR_Init()
> PWR_vForceRadioRetention(TRUE)

So far, my development does not use Zigbee/Thread, PDM and standard MAC library. I use SDK driver examples and some piece of code of MMAC in `thead' source code or some older MMAC projects.

Also I checked the source code from PWR library, it just set PM_CFG_RADIO_RET flag for POWER_GoToPowerDown().

I'm checking the example AN-1245 again, and found that GpEhSwich/ is using MMAC. But I could not find the code going to sleep part, and I could not find any description about sleeping of this GpEhSwich sample. Is this really sleeping sample of MMAC?

Since MMAC library is so simple and small, I guess, there is very simple procedure for wake/sleep procedure. Any of information is welcome.

Thanks for supporting!
Seigo

0 件の賞賛
返信
18,207件の閲覧回数
EduardoZamora
NXP TechSupport
NXP TechSupport

Hello,

I truly apologize for the delay.

JN-AN-1245 GpEhSwitch should put the device to sleep ( POWER_EnterSleep() ) if there are no activities in progress or after a command transmission using vSendMACFrame().

Could you please help me confirm if the implementation of MMAC in this App Note is what you are looking for?

Regards,
Eduardo.

0 件の賞賛
返信
18,199件の閲覧回数
usaygo
Contributor III

Hi Eduardo,

I'm keeping trials to identify what is missing. I have reasons that I can't use components API like PWR, because I need to handle many of Jennic based old codes using pure AHI library and standard MAC API (AppAPI).

Now I have a very same question again. The vAppApiSaveMacSettings() vAppApiRestoreMacSettings() with PM_CFG_RADIO_RET and SRAM retention flag is the right way to sleep(power down) and waking up procedure to keep radio settings without longer re-initialization. Is it the correct understanding?

The vAppApiRestoreMacSettings() still takes longer time (80ms approx.).

//Seigo

 

The details follow...

>  POWER_EnterSleep() 

It's not power down sleep, just a kind of doze mode.

 

// from fsl_power.h
#define POWER_ENTER_SLEEP()  __DSB(); __WFI(); __ISB();
static inline void POWER_EnterSleep(void)
{
    POWER_ENTER_SLEEP();
}

 

I decided to giving up using MMAC, just gonig back to AppAPI. The AppAPI seems base API implementing ZigBee stack. I guess this is closer to the solution.

The latest trial is going back to AppAPI (starting from u32AppApiInit(), not using MMAC APIs). The sleeping and waking up procedure is like below:

 

//---- on cold boot ----
u32AppApiInit(...); // register callbacks and init MAC.
s_pvMac = pvAppApiGetMacHandle();
MAC_vPibSetPanId(s_pvMac, 0x1234); // set some value
MAC_vPibSetShortAddr(s_pvMac, 0x0000); // set some value
eAppApiPlmeSet(PHY_PIB_ATTR_CURRENT_CHANNEL, 11); // set 11 to 26
MAC_vPibSetRxOnWhenIdle(s_pvMac, TRUE, FALSE); // Open Rx channel
//then... a transmitting packet request will report a success event.

//---- before sleeping ----
WTIMER_Init();
WTIMER_EnableInterrupts(WTIMER_TIMER0_ID);
WTIMER_StartTimer(WTIMER_TIMER0_ID, 1 * 32768U);
pm_power_config_t pm_config = {0};
pm_config.pm_config |= PM_CFG_SRAM_ALL_RETENTION;
pm_config.pm_wakeup_src |= POWER_WAKEUPSRC_WAKE_UP_TIMER0; // CHOOSE WTIMER0
pm_config.pm_config |= PM_CFG_XTAL32M_AUTOSTART;
pm_config.pm_config |= PM_CFG_RADIO_RET;

vAppApiSaveMacSettings(); //--- SAVING MAC STATE (APP API)

POWER_EnterPowerMode(PM_POWER_DOWN, &pm_config);
//(this will call POWER_GetPowerDownConfig() and POWER_GoToPowerDown())

//---- after waking ----
vAppApiRestoreMacSettings(); // THIS WILL ALSO TAKE 80ms...
//... after restoring, a transmitting packet request will report a success event.

 

 

Looking into AN-1245, the necessary procedure seems vAppApiRestoreMacSettings() called during waking up procedure. Unfortunately, I still taking longer time (80ms approx.) even the PM_CFG_RADIO_RET flag is present at POWER_EnterPowerMode(PW_POWER_DOWN,...) or POWER_GoToPowerDown(). The MAC seems working well, where packet transmission request reports a success event.

Anyway, I took glances at most of code in PWR.c or PWRLib.c, howeve I cold not find anything more... I don't see what I should do next... Do you have any suggestions?

0 件の賞賛
返信
18,039件の閲覧回数
EduardoZamora
NXP TechSupport
NXP TechSupport

Hello,

I just sent you a private community message, please take a look at it.

Regards,
Eduardo.

0 件の賞賛
返信
18,272件の閲覧回数
usaygo
Contributor III

Hi Eduardo,

It needs detailed checking, however, the following procedure call sequece would go.

before sleeping,

  • vMMAC_Disalbe() <- I wonder this would close RADIO...???
  • go POWER DOWN (with RADIO RETENTION and AUTOSTART 32M XTAL)

after waking,

  • // skip vMMAC_Enable();
  • vMMAC_ConfigureRadio();

 

The functional checking has not done. I will try it next. Please keep this thread on.

 

 considering the suggestions from my previous reply?

What part of your suggestion do you mean?

> PWR_ChangeDeepSleepMode(PWR_E_SLEEP_OSCON_RAMON)

I think it's not the matter. I think POWER_DOWN is not bad choice.

> PWR_Init()

It seems library initialization.

> PWR_vForceRadioRetention(TRUE)

This call will pass the RADIO RETENTION flag to POWER_GoToPowerDown(). I don't see any other important code here.

> and manage temperature update in application
> #define RADIO_TEMP_UPDATE TRUE

Is it mandate just to confirming waking up MMAC initalization process? (and ... I don't see this definition is the part of MMAC library...)

> Please, refer to JN-AN-1245, RAMOPT=0 build option for these implementations.
> Please consult JN-AN-1245 > Doc > JN-AN-1245-Release-Notes for more details on SDK compatibility.

By seeing AN-1245, the project definition will load "AppBuild16kEndDevice_JN5189.ld" as linker script. Will it be the required build condition for MMAC usage?

 

 

 

0 件の賞賛
返信