-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LPC11u24 deepsleep interface disconnect #143
Comments
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. |
Hello Erik, Is this issue solved? If yes, please close this issue. I can see that is macro protected now.
|
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. |
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. |
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). |
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. |
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. |
Circle - add building tests for k64f
ARM Internal Ref: IOTMORF-328 |
Updating mbed-os to mbed-os-5.10.4
Something which I think is better to mention here before I go ahead and remove it and create a pull request. The issue:
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).
The text was updated successfully, but these errors were encountered: