LPC11u24 deepsleep interface disconnect

[Sissors]

Something which I think is better to mention here before I go ahead and remove it and create a pull request. The issue:

void deepsleep(void) {
    // ensure debug is disconnected
    mbed_interface_disconnect();

    // PCON[PD] set to deepsleep
    LPC_PMU->PCON = 0x1;

    // SRC[SLEEPDEEP] set to 1 = deep sleep
    SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;

    // Power up everything after powerdown
    LPC_SYSCON->PDAWAKECFG &= 0xFFFFF800;

    // wait for interrupt
    __WFI();
}

Since the M0 core is not debug aware, it will always try to disconnect the mbed interface. If there is none (ie: Seeeduino Arch, DipCortex, but also when powering it from battery), it will hang/crash there. It only works if the original LPC11u24 is fully powered.

Why is it called? Because it cannot enter deepsleep when debugger is connected. However that is only partially true. Yes, the power consumption is high when deepsleeping with debugger connected (I assume this, that was the case with the KL25Z, I cannot easily measure it on the mbed LPC11u24). However considering it only actually works with the complete mbed powered, that is probably the least of your issues. Considering the interface isn't powered down, it still consumes power. The voltage regulators already consume combined 10mA quiescent current.

I ran some tests, and also with debugger outside of power consumption it seems to behave pretty much the same: peripherals are shut down, so my regular timer interrupt was never called while in deepsleep. Wakeup time from an external interrupt was within the measurement uncertainity for debugger connected and disconnected.

So the TL;DR, I would propose removing that line, outside of power consumption it doesn't do anything, and power consumption is huge anyway with the complete board powered.
Advantage is that it actually works on the other boards with the LPC11u24, and when powered via the battery pin, which is the case when you want it low power.

And finally, from the sleep modes I made I always put it in the equivalent of powerdown instead of deepsleep, just changing one bit in the code here: Compared to deepsleep it takes barely longer to wakeup, the only relevant difference is that flash memory is in standby instead of running, but it consumes alot less power. (That is according to the datasheet and my experience with KLxxs and LPC812, on my LPC11u24 board I still have a 400uA unaccounted for).
My own measurements give roughly 20us longer required for waking from powerdown (on a total of 680us).

[neilt6]

I agree with this, not only does it affect development boards without an interface chip, but it affects any production boards using the mbed SDK as well.

[0xc0170]

Hello Erik,

Is this issue solved? If yes, please close this issue. I can see that is macro protected now.

    // ensure debug is disconnected
    #if DEVICE_SEMIHOST
    mbed_interface_disconnect();
    #endif

[Sissors]

Actually, no :P. That fixes it on devices without semihost (such as the seeeduino arch), but it imo should be completely removed. For reasons see above :). And personally I would put it in powerdown instead. Also PDAWAKECFG should only wake with is currently enabled (easy to make), instead of everything.

But since in the meantime I started doing other stuff and with only Neil's reaction on it I didn't feel like changing the original mbeds behavior.

[neilt6]

Aside from LocalFileSystem (which isn't going to be around forever since the mbed interface is deprecated now), what benefit does semihosting offer? All I see are drawbacks. For example, the mbed-rtos library can't put the chip to sleep in the idle thread because it might disconnect from semihosting. So what's the point of an idle thread then? I'm of the opinion that semihosting needs to bite the dust entirely.

[Sissors]

Heh it understands I referenced this. Pull request in to change this, then I close it ;).

Btw I agree with Neil. LocalFileSystem is a very neat thing to have, but in general the semihosting interface is not the greatest thing since sliced bread. Although it can't put it to sleep in idle thread? Never tried it, but regular sleep works fine. Although also the others I have tried all end up in a debugging state when the interface chip is also powered, so including newer mbeds. (You notice that since its powerdown consumption is a few milli-amps instead of micro-amps).

[Sissors]

Pull request was cancelled. The bug is still there, so hopefully mbed staff fixes this in the future. With some toying around I made my lpc11u24 semi debug-aware, so maybe something like that would meet the requirements.

[Sissors]

Old one, but what I just considered: Did anyone ever checked if the disconnect command to the mbed interface does even have any influence whatsoever on the state of the target (the LPC11u24)? I ask because I recently had some discussions with an ARM colleague of yours (mbed staff), Yunfei Niu, and he wasn't able to really get the LPC1768 out of the debug mode it is standard in. In addition personally I haven't been capable of getting any target out of debug mode without power cycling: Just resetting the microcontroller also never did the job.

[ciarmcom]

ARM Internal Ref: IOTMORF-328