When I put the following circuit into deep sleep with NRF_POWER->SYSTEMOFF = 1; the attached vibration motor turns ON and will not stop.
It will only stop buzzing once the RESET is pressed, or if the power is removed (currently via USB).
Replacing the vibration motor with an LED as an sanity check revealed no issues. This seems to be a circuit design error then, but I don’t understand where or why?
Why should the motor turn ON and continually run when the MCU goes to sleep?
Hi there,
Depending on the GPIO it may have the weak pull-up/down resistor in place, Check the port number and pin number is it a LP compatible GPIO or what? look at the pins XLS in the wiki and consult the technical reference guide for more.
HTH
GL 
PJ 
Once you get it correct it will work like the led.
@PJ_Glasso Would you mind helping with this a bit further?
So, I looked up the A4 PIN in the XLXS spreadsheet:
and then the schematic:
But I don’t see any more information for this pin regarding the resistor in place. I’m not sure where to take this further. I checked the nRF52840 product specification but didn’t recognize anything as helpful there
The GPIO pull-up and pull-down resistors are described in the datasheet “6.9.3.1 GPIO Electrical Specification” and are approximately 13 kΩ. The GPIO can be set to be used in the register, but by default it is not used.
@msfujino Thanks for the information. Could you help me out a bit more with understanding this?
I assumed the power would be cut to any GPIO pin during deep sleep. I can easily just do a digitalWrite(A4, LOW); before entering sleep to ensure the power is off, but this seems redundant, though necessary here.
i dont really understand how the buzzer works… but i am thinking what is going on is the GPIO pins have sometimes pull up or pull down resistors built in internally… sometimes they can be controlled by software… the pull up resistor brings the pin high and the pull down resistor brings the pin low… this is done to ensure the pin stays at a logic level 0 or 1 unless it is commanded to change… you may need to just change the logic level that controls the device… for example… if the GPIO is naturally going to 0 when in sleep mode then you need to change the connected device to be off at logic level 0 and on in logic level 1… hope that helps
What is the link to the motor you are using?
Where is the pin “IN” resistor connected?
Base or GND?
During DeepSleep, how many volts is the “IN” terminal, 3.3V or 0V?
Thank you for the link, as it solves my question about the GPIO PINS. I’m not sure if I should make another thread, but now I am finding the opposite with the PIN responsible for battery charging.
If I put the Xiao Sense into deep sleep, the charging LED will turn on, but the battery does not charge
How did you check that the battery was not charging?
From the schematic, it appears that Sleep and charging are unrelated.
I didn’t have a hard measure way to determine this. But the evidence for it is as follows:
I connected a nearly depleted battery yesterday, connected a USB-C, and set the MCU into deep sleep. The charging LED was on. On awakening the device it quickly shut-off again, and by all appearances the battery did not charge. I tried this several times
Next I left the device on (the same code as before, just no command to sleep over BLE) and after 30 minutes of charging the battery was clearly working
In short, after 2 hours of “charging” during deep sleep, the battery accumulated no appreciable charge. After 30 minute of charging during awake, the battery accumulate significant charge
During DeepSleep, it is easy to determine whether the battery is charged or not by measuring the battery terminal voltage.
According to the circuit diagram, the charge controller seems to be independent of DeepSleep.
edit
I have experimented with this. The battery continues to be charged at 50 mA during DeepSleep.
With your setup information and a sketch, I can try your situation here too.
