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?
已解决! 转到解答。
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.
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.
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!
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.
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)
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?
Thank!
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.
> 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.
Another example from "Power API demo v1.0" with sleep and wakeup.
It still take 80ms approx even waking after the sleep.
//Seigo
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!
/* 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();
}
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:
Thanks!
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.
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?
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.
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.
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
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.
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?
Hi Eduardo,
It needs detailed checking, however, the following procedure call sequece would go.
before sleeping,
after waking,
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?