Timeout during sleep().

25 Jan 2012

Hello all,

I have an interesting problem with the new sleep method. I'm trying to set up a recurring timer event, and sleep between each event (to save power). This seems like a fairly typical use-case, but I cannot get it to work beyond the first sleep. I tried to reduce it to the simplest case:

DigitalOut led1(LED1);
DigitalOut led2(LED2);
Timeout to1;
Timeout to2;

void led1_on() { led1 = 1; }
void led2_on() { led2 = 1; }

int main() {
    led1 = 0;
    led2 = 0;
    to1.attach_us(led1_on, 1000000);
    to2.attach_us(led2_on, 2000000);
    while (1) {
        printf("Entering sleep.\n");
        sleep();
    }
}

The first event fires correctly, and wakes the processor from sleep. The second event does not, however, and only the first LED lights up. The order in which they are attached makes no difference. Also, the same effect is seen using the Ticker class, in that only the first tick event fires.

I'm fairly sure that there's a bug in the sleep implementation, but have I missed something obvious here?

25 Jan 2012

Ah-ha, I can answer my own question. The m0-beta library seems to exhibit the proper behaviour here, at least at the moment.

The m0-beta library can be imported from here (replacing the default 'mbed' library): http://mbed.org/projects/libraries-testing/svn/m0-beta

26 Jan 2012

Jacob Bramley wrote:

I'm fairly sure that there's a bug in the sleep

Thanks Jacob, you are right, there was a bug in the "sleep", introduced when I fixed another bug in the interface reset: http://mbed.org/forum/mbed/topic/3045/

The "sleep" code needs to actually detach the debugger (sleep is disabled during debugging). The M0 does not have an efficient way to detect if the debugger is attached, assuming that the debugger is attached was not a safe option. We are now properly tracking the state of the debugger (interface chip) connection. [Rev. 38]

Cheers, Emilio

26 Jan 2012

Jacob Bramley wrote:

The m0-beta library seems to exhibit the proper behaviour here [...] (replacing the default 'mbed' library)

Just to avoid confusion, let me clarify that we have now merged all the changes from "m0-beta" to the "mbed" trunk.

Cheers, Emilio

06 Aug 2013

Hi folks Apologies for being dense, is there any documentation for the sleep function - I can't find it anywhere on the hadnbook page. It doesn't seem to appear in the mbed classes on the compiler so I'm a bit unsure of what it does and what runs while the unit is sleeping. Things like, do the timers still run ? which interrupts can be used etc are not documented.... unless I'm looking in the wrong place ?

chris

06 Aug 2013

You are correct that kinda lacks documentation. The sleep support could be better, I think one of the problems is that the way the interface chip on the LPC1768/11u24 are connected prevents some of the sleep options. But the user manuals should provide the relevant data.

But the LPC1768 documentation from its user manual on sleep for example:

Quote:

Note: Sleep mode on the LPC17xx corresponds to the Idle mode on LPC2xxx series devices. The name is changed because ARM has incorporated portions of reduced power mode control into the Cortex-M3. LPC17xx documentation uses the Cortex-M3 terminology where applicable.

When Sleep mode is entered, the clock to the core is stopped, and the SMFLAG bit in PCON is set, see Table 44.Resumption from the Sleep mode does not need any special sequence but re-enabling the clock to the ARM core.

In Sleep mode, execution of instructions is suspended until either a Reset or an interrupt occurs. Peripheral functions continue operation during Sleep mode and may generate interrupts to cause the processor to resume execution. Sleep mode eliminates dynamic power used by the processor itself, memory systems and related controllers, and internal buses.

The GPDMA may operate in Sleep mode to access AHB SRAMs and peripherals with GPDMA support, but the GPDMA cannot access the flash memory or the main SRAM, which are disabled in order to save power.

Wake-up from Sleep mode will occur whenever any enabled interrupt occurs.

Please log in to post a reply.