cc2538 low power mode access? about contiki-ng HOT 15 OPEN

Sounds like no rtimer was scheduled. This is usually taken care of by a duty-cycling MAC protocol.

from contiki-ng.

Thank you @kkrentz Is this something to be modified in the board.h file? I am currently using a timer with:
etimer_set(&timer, CLOCK_SECOND * 5);
PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&timer));
etimer_reset(&timer);

from contiki-ng.

etimer is a different thing. Contiki-NG uses the scheduled rtimer to determine which sleep mode to enter. TSCH (as well as my implementations of CSL and ContikiMAC) do this for you. The default CSMA MAC protocol, however, does not. You could either swap the MAC protocol or set the rtimer yourself by calling rtimer_set.

from contiki-ng.

Hello @kkrentz I have tried to set the rtimer and then enter in low-power mode but the consumption does not change. Please, let me attach my main file and the configuration of the platform.
deploids-conf.txt
hello_world.txt

Do you have any example based on cc2538 to enter into low-power?
Best regards,

from contiki-ng.

I recall that rtimer_set is not enough. Additionally, the radio must be disabled, but the default CSMA MAC never does so.

Here is an example with my MAC protocol: https://github.com/kkrentz/contiki-ng/tree/master/examples/akes/csl. It should also work if you switched to TSCH.

from contiki-ng.

Thank you @kkrentz . By applying NETSTACK_MAC.off(); the consumption gets reduced from 28 to 12mA. I think TSCH is also considered in the configuration with:
#define RADIO_PHY_OVERHEAD CC2538_PHY_OVERHEAD
#define RADIO_BYTE_AIR_TIME CC2538_BYTE_AIR_TIME
#define RADIO_DELAY_BEFORE_TX CC2538_DELAY_BEFORE_TX
#define RADIO_DELAY_BEFORE_RX CC2538_DELAY_BEFORE_RX
#define RADIO_DELAY_BEFORE_DETECT CC2538_DELAY_BEFORE_DETECT

But I do not know what may be causing the rest of the consumption. Any other interface that I should consider?

from contiki-ng.

12mA is about the consumption in LPM 0. I would suggest you to add some printfs to lpm_enter in lpm.c to find out what is preventing a deeper sleep mode.

from contiki-ng.

Dear @kkrentz , following your recommendation I have discovered that the cc2538 gets in an else in lpm.c with the following content:
/*
* Anticipated duration too short for PM2 but long enough for PM1 and we
* are allowed to use PM1
*/

Hence, it enters into PM1 but then the cc2538 aborts because process_nevents() returns 1 so then applies:
select_32_mhz_xosc();
REG(SYS_CTRL_PMCTL) = SYS_CTRL_PMCTL_PM0;
How may I ensure that process_nevents is reduced to 0?
Best regards.

from contiki-ng.

A possible explanation is a process calling process_post or process_poll again and again. To dig deeper, maybe disable the networking altogether by inserting this into your Makefile:

MAKE_MAC = MAKE_MAC_NULLMAC
MAKE_NET = MAKE_NET_NULLNET

from contiki-ng.

Dear @kkrentz after applying MAKE_MAC and MAKE_NET values in the makefile, process_nevents seems to keep returning 1. This change seems that does not take effect on the lpm. Maybe this is because the process running is related to another interface different than the radio?

The value 1 comes from poll_requested variable.

Best regards.

from contiki-ng.

This snippet prints the name of the process that called process_poll:

process_poll(struct process *p)
{
  printf("poll by %s\n", p->name);

My CSL example enters LPM 1+ between each duty cycle on the OpenMote board, but maybe a platform-specific issue exists.

from contiki-ng.

Thank you very much. The name of the poll_request printed is "Event Timer" and "Serial Driver". In my main file I have:

while(i < 5) {
ct = clock_time();
rt_now = RTIMER_NOW();
rt_for = rt_now + RTIMER_SECOND;
rtimer_set(&rt, rt_for, 1, rt_callback, NULL);
i++;
}
printf("Hello, worldd\n");

lpm_init();

while(1) {
ct = clock_time();
rt_now = RTIMER_NOW();
rt_for = rt_now + RTIMER_SECOND;
rtimer_set(&rt, rt_for, 1, rt_callback, NULL);
lpm_enter();
}

I understand that the event timer is that rtimer_set, but if I do not apply it, the board never tries to get to lpm 2. About the serial driver I understand that may be the uart used to print messages.

from contiki-ng.

Actually, it should not be necessary to interact with lpm manually. After the first rtimer_set, you can exit the process and set a new rtimer callback within rt_callback. I do not see "Serial Driver" on my OpenMotes. "Event Timer" seems normal.

from contiki-ng.

Thank you. Hence, in my main file I do:
ct = clock_time();
rt_now = RTIMER_NOW();
rt_for = rt_now + RTIMER_SECOND;
rtimer_set(&rt, rt_for, 1, rt_callback, NULL);
printf("Hello, worldd\n");

lpm_init();
PROCESS_END();

And my rt_callback function:
rt_callback(struct rtimer *t, void *ptr)
{
rt_now = RTIMER_NOW();
ct = clock_time();
}

Using this code, I see that it enters into lpm2 "ENERGEST_SWITCH(ENERGEST_TYPE_CPU, ENERGEST_TYPE_DEEP_LPM); " reducing the current to 2mA. By extending the rt duration, the 2mA is maintained. Is 2mA a normal consumption for LPM2?

from contiki-ng.

On OpenMote-A, I think I also reached only down to 1-2 mA in LPM 1+. I am not aware if this was fixed in OpenMote-B or if a bug in Contiki-NG is the actual cause.

BTW, even lpm_init is unnecessary and within rt_callback an rtimer_set is required to restart the rtimer.

from contiki-ng.