Problems with an output pin controlling boost converter | adafruit | Page 1

frozen granite Oct 13, 2025, 10:20 PM

#

I was controlling the 4654 boost regulator with one pin from the feather. We started with A0, but weird issues occurred, and my buddy suggested we move to another pin. We went to D13, only to discover that it was also driving an LED on the board. We are now using D12.

When NOT plugged into USB, it seems to run fine, turning the output pin on for 20 seconds then off for 30 seconds, repeat.

When the USB is plugged in, the console output is visible, and it thinks it's running, but the pin is NOT being controlled. I can find no reference as to what the interference could be. Any ideas?

#

We are using Circuit Python 9+

#

Here is the setup code

# Fan Control Pin setup
# Fan control hardware is on pin D12
# This is the only place where the pin is defined.

print("Pin D12 initialization")
    
fan_pin = DigitalInOut(board.D12)
fan_pin.direction = Direction.OUTPUT

def fan_on():
    fan_pin.value = True
    print("FAN ON")

def fan_off():
    fan_pin.value = False
    print("FAN OFF")
    
fan_off()

fair basalt Oct 13, 2025, 10:22 PM

#

i'll look up the schematic for that mini boost...

frozen granite Oct 13, 2025, 10:22 PM

#

Factory is a 100K pullup on the enable pin. I have changed it to a 4.7K pull-down, experimentally.

#

It is unclear what changes when the USB is plugged in to change the behavior.

fair basalt Oct 13, 2025, 10:24 PM

#

all the grounds are tied together?

frozen granite Oct 13, 2025, 10:24 PM

#

Yessir.

fair basalt Oct 13, 2025, 10:28 PM

#

frozen granite Oct 13, 2025, 10:28 PM

#

yes

fair basalt Oct 13, 2025, 10:28 PM

#

could you post the code?

frozen granite Oct 13, 2025, 10:28 PM

#

Er..... other channel.

fair basalt Oct 13, 2025, 10:29 PM

#

oops, missed it while I was importing it into eagle 🙂

#

The pin value is going to revert when the program finishes. Is there more to the program? If not, add while True: pass at the end

frozen granite Oct 13, 2025, 10:30 PM

#

I posted my full (non-public) code to DM

#

It uses DeepSleep

fair basalt Oct 13, 2025, 10:32 PM

#

so if you use the really simple code above, is D12 controlled properly? Or just try it from the REPL and look at the pin voltage

frozen granite Oct 13, 2025, 10:32 PM

#

The code works fine when not plugged into USB.

fair basalt Oct 13, 2025, 10:33 PM

#

when USB is connected in the full program, it will do a "fake" deep sleep. So maybe there is a bug that is not preserving D12

#

I am not sure if the preserved dio will have full drive during sleep. DId you see this problem before you added the strong pull-down?

#

the preserve dio was originally added for Espressif boards, and might not be implemented properly on atmel-samd

#

wait sorry, I am stuck in atmel-samd mode -- I was debugging something with that. Need to reset my brain. THis is an ESP32-S3.

frozen granite Oct 13, 2025, 10:37 PM

#

Aye

fair basalt Oct 13, 2025, 10:41 PM

#

looking at the code... it's looking like it only does the preservation in real deep sleep, but I need to look further

frozen granite Oct 13, 2025, 10:42 PM

#

Is there a CircuitPython command to re-boot?

fair basalt Oct 13, 2025, 10:42 PM

#

microcontroller.reset()

#

is a hard reset

frozen granite Oct 13, 2025, 10:47 PM

#

Is there a soft reboot??

#

(just for troubleshooting)

#

(I am replacing the DeepSleep with my own time.sleep() and hopefully a soft reboot)

fair basalt Oct 13, 2025, 10:48 PM

#

a deep sleep restart is a hard reset

frozen granite Oct 13, 2025, 10:49 PM

#

I am trying to keep my console output.

fair basalt Oct 13, 2025, 10:49 PM

#

more or less

#

sys.exit(0) or just return or fall off the end of the program. Not sure you can return; I forget (no one does that 🙂 )

frozen granite Oct 13, 2025, 10:50 PM

#

What does sys.exit(0) do?

fair basalt Oct 13, 2025, 10:50 PM

#

should restart the VM

#

or maybe just go to REPL prompt; I forget.

#

When you say you don't want to lose console output, what do you mean? which terminal program are you using?

frozen granite Oct 13, 2025, 10:54 PM

#

MS Visual Studio

fair basalt Oct 13, 2025, 10:55 PM

#

does it not reconnect after losing the connection?

#

in any case, the correct thing to do is supervisor.reload(), which will restart code.py. sys.exit(0) goes to the REPL. (I just did some experiments)

frozen granite Oct 13, 2025, 10:56 PM

#

AHA!

#

Trying

fair basalt Oct 13, 2025, 10:56 PM

#

which OS are you using ... Windows?

frozen granite Oct 13, 2025, 10:56 PM

#

Y

fair basalt Oct 13, 2025, 10:56 PM

#

Tera Term will reconnect. There aren't many others that will.

#

Looking at the code, I think preserve_dios is not doing the right thing in fake deep sleep. In fake deep sleep, the pins may all get reset because the VM finished. But I would need to do some experiments

frozen granite Oct 13, 2025, 10:58 PM

#

I might have it....

#

Is there a way to detect if you are plugged into USB?

fair basalt Oct 13, 2025, 11:00 PM

#

supervisor.runtime.usb_connected and supervisor.runtime.serial_connected (which mean different thigns)

frozen granite Oct 13, 2025, 11:00 PM

#

will test

#

(yer awesome.... thank you)

fair basalt Oct 13, 2025, 11:00 PM

#

serial connected means there's a CDC port.

#

well, i have to know all this, or at least know where to look. I wrote the preserve_dios code but it was several years ago

frozen granite Oct 13, 2025, 11:05 PM

#

    time_alarm = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + SleepTime)

    if not supervisor.runtime.usb_connected:
         print("USB connection not detected.")
         alarm.exit_and_deep_sleep_until_alarms(time_alarm, preserve_dios=(fan_pin,))
    
    print("USB connection detected.")
    time.sleep(SleepTime)
    supervisor.reload()

    # (does not return)

#

This seems to be working great.

fair basalt Oct 13, 2025, 11:09 PM

#

I looked at the code. It will fake deep sleep exactly when supervisor.runtime.usb_connected is true, so you are right on target.

#

I think there may well be a bug with preserve_dios and I will open an issue about that.

frozen granite Oct 13, 2025, 11:10 PM

#

I am still getting a blip on the fan... trying to track that down.

fair basalt Oct 13, 2025, 11:12 PM

#

definitely something to watch on a scope or analyzer. There may be a glitch around restart time because the pins are reset

frozen granite Oct 13, 2025, 11:12 PM

#

That's what it seems like.

#

Strange result.....

When running not on USB, at reboot after DeepSleep, the pin comes up at 2.2V for about four seconds, then drops to zero, then comes on normally at 3.2 volts and the program proceeds.

#

This is with a 4.7K pulldown.

fair basalt Oct 13, 2025, 11:22 PM

#

the best default state of ESP pins is pulled high with the internal pull-up. This is the most power-saving setting, according to the mfr. We reset into that state. But I'm not sure what the state is on a hard reset

#

are there wifi settings in settings.toml? if so, it is making a connection, which may take about four seconds

frozen granite Oct 13, 2025, 11:24 PM

#

I guess I can go harder on the pull down and see.

fair basalt Oct 13, 2025, 11:25 PM

#

I think the preserve settings may go away after the reset. That code was written long before the auto-connect feature

frozen granite Oct 13, 2025, 11:25 PM

#

The very first thing we do on boot is establish the pin and go low.

fair basalt Oct 13, 2025, 11:25 PM

#

try renaming settings.toml and see what the levels look like

#

are you doing that in code.py or boot.py?

frozen granite Oct 13, 2025, 11:26 PM

#

main.py

#

wait...

#

Actually, I do have something in boot.py

#


# D12: Fan/EN control — hold LOW so the regulator/fan stays OFF at boot.
try:
    microcontroller.pin.D12.switch_to_output(value=False)
except AttributeError:
    # Fallback for boards where D12 alias isn't on microcontroller.pin
    import board, digitalio
    p = digitalio.DigitalInOut(board.D12)
    p.direction = digitalio.Direction.OUTPUT
    p.value = False

fair basalt Oct 13, 2025, 11:28 PM

#

This will never work: microcontroller.pin.D12.switch_to_output(value=False). switch_to_output is only on DigitalInOut's

frozen granite Oct 13, 2025, 11:28 PM

#

will delete boot.py

fair basalt Oct 13, 2025, 11:29 PM

#

do a hard reset after that, it only runs after a hard rest

#

it will attempt to do a wifi connect before boot.py, it looks like, if CIRCUITPY_WIFI_PASSWORD and CIRCUITPY_WIFI_SSID are set

#

you can just do the connect yourself manually in code.py, unless you want the web workflow

frozen granite Oct 13, 2025, 11:33 PM

#

Do you mean that it will try to restore a wifi connection? Do I have to take it down before DeepSleep? I can do that.

fair basalt Oct 13, 2025, 11:34 PM

#

you don't have to take it down, but if you have those values defined in settings.toml, it will set up a connection upon restart

#

which takes time

frozen granite Oct 13, 2025, 11:35 PM

#

is there a "wifi.radio.disconnect()"??

fair basalt Oct 13, 2025, 11:37 PM

#

there is wifi.radio.enabled = False and wifi.stop_station().

fair basalt Oct 13, 2025, 11:53 PM

#

bug of interest: https://github.com/adafruit/circuitpython/issues/9622

#

I opened https://github.com/adafruit/circuitpython/issues/10667

frozen granite Oct 14, 2025, 12:02 AM

#

OK.... I have a fix. Changing to a 2.2K pull down does it. I can't explain what is going on during boot-up, but the four seconds where the fan was previously running is gone. The voltage on the now-heavily-loaded D12 only reaches 0.16v during this period, and does not fire the boost regulator. When the program starts running, it activates the regulator normally. This works for me, though it is inelegant.

fair basalt Oct 14, 2025, 12:07 AM

#

I think this may well have to do with the internal pull-up being enabled at some point before you have a chance to deal with it. They are about 45k ohms

#

but the 2.2v doesn't match with that 🙁

#Problems with an output pin controlling boost converter