First post here. I might be missing something, but I’ve observed some unusual behavior that I can’t explain when I try to turn power off to the uSD on the MMDLCB (with Artemis MicroMod w/ core v2.2.0).
Looking at the schematic, when I drive the particular GPIO pin low (ARTEMIS PIN 33, 3.3V_LP), this should disable the LDO and cut power to the uSD. However, I actually see an observed Increase in current draw by ~200mA.
Conversely, this same exercise with the GPIO that enables QWIIC power results in lower current draw when driven low, as expected.
Please note that due to design flaws with both the Artemis Processor and MMDLCB, you generally won’t be able to achieve lower than several hundred uA in deep sleep. Also, from what I’ve read v2.x of the Apollo3 Core is not as power efficient.
At first, I was using pretty much the same code as what you shared, however with the HAL “force peripherals off” and “disable pads” commented out since they seem to cause issues with v2.x core (perhaps another forum post for another time, and I can’t downgrade to v1.x without running into bootloader problem when trying to upload code).
To simplify things, I reduced my code to a simple test, simply cycling between driving the particular pin high or low. Interestingly, I see about 30mA greater power draw when driving the LDO enable low, which doesn’t happen for the QWIIC LDO… I should have mentioned this only happens with SD card inserted. Without SD card, current draw drops by ~.5mA when the pin is driven low, which at least is in the right direction.
#define PIN_SD_POWER 33 // G1 - Drive low to turn off SD/Perhipherals
#define SD_CONFIG SdSpiConfig(41, SHARED_SPI, SD_SCK_MHZ(24))
#include <SdFat.h>
#include <SPI.h>
SdFs sd;
void setup() {
//Serial.begin(115200);
digitalWrite(PIN_SD_POWER, LOW);
pinMode(LED_BUILTIN, OUTPUT);
delay(2000);
}
void loop() {
// TURN PERIPHERAL uSD ON
SPI.begin();
digitalWrite(PIN_SD_POWER, HIGH);
digitalWrite(LED_BUILTIN, HIGH);
delay(100);
if (!sd.begin(SD_CONFIG)) { // https://github.com/sparkfun/Arduino_Apollo3/issues/370
Serial.println("Card failed, or not present. Freezing...");
while (1);
}
// TURN PERIPHERAL uSD OFF
delay(5000);
SPI.end();
digitalWrite(PIN_SD_POWER, LOW);
digitalWrite(LED_BUILTIN, LOW);
delay(5000);
}
I tested your code on v2.2.0 and v1.2.3 of the Apollo3 Core. When using v2.2.0 I can confirm that when the LDO that provides power to the microSD is disabled, the current draw jumps to ~19 mA. This behaviour was not observed with v1.2.3 of the Apollo3 Core, which resulted in an expected current draw of ~1 mA.
It sounds like this may be another bug with the Apollo3 Core (and underlying Mbed OS). I know the OpenLog Artemis was recently upgraded to v2.x of the Apollo3 Core, but I don’t know if Paul confirmed the quiescent draw when the microSD is disabled. The OLA also uses a P-MOSFET to control power to the microSD, though I don’t believe this would make a difference, as it’s likely a software-related problem.
It sounds like opening up a new issue on GitHub would be the next best step. I’d also be happy to try to help you get things working with v1.2.3. I suspect I’ll be sticking with this version of the Apollo3 Core for some time to come.
Glad to hear it wasn’t just me experiencing this issue. I’ll go ahead and submit a Github issue report. In the meantime, looks like everything is working as expected with v1…
In my [code, I had set the pins as outputs and still measured the high current draw with the LDO disabled.
I haven’t had the time to break out the multimeter, but I’d be curious to see what the voltages are on the microSD pins. Were there any fundamental changes to SPI with the switch over to Mbed OS?
SPI implementation on V2.x is different than V1. Especially the SPI.end() is very different. On the V1 it really de-initializes and disables the SPI IOM, on V2 the intention is to only delete the MBED instance, which was allocated during SPI.begin(). It is ‘the intention’ because the check is incorrect. Not deleting is not a concern right now. Deleting the instance will just release memory. Still, I will raise a bug for it as it is incorrect.
But whether or not deleting nothing else happens on SPI.end() in V2… no de-initialization… not shutting down the power on the SPI-IOM, no stopping of potential transactions pending/in progress. etc. (p.s. The same is true for Wire…)
I checked the GPIO settings between V1 and V2. They look to be the same (pushpull / 12mA) .
I have tried the sketch on Openlog HW and tried different ways (V1.2.3 and V2.2.0) and different conditions. I have added to do disabling and going to deep sleep and tested that condition. Change the check to delete the SPI-instance at end, couple of hours different tests and analyses
In ALL cases and tests I get the exact same mA result. No difference whether using V1.2.3 or V2.2.0
Now the Openlog does not have an LDO for the SD. It is using a FET to enable /disable SD power. Later this week I expect an MMDLCB and Artemis processor board and will try on that.
In the meantime, I wonder whether it would make a difference to do an sd.end() before SPI.end, in order to stop this library. I also wonder about the impact to write pin 41 (CS) HIGH after sd.end() and before doing SPI.end().