[GH-ISSUE #281] Coldboot not flashing LED #128

New issue

Open

opened 2026-10-22 05:05:14 +00:00 by roman · 48 comments

roman commented 2026-10-22 05:05:14 +00:00

Owner

Copy link

Originally created by @sponge on GitHub (Sep 8, 2026).
Original GitHub issue: https://github.com/safijari/openpuck/issues/281

Hello!

I'm trying to get the new cold boot feature to work. I verified I'm on the right pin by blinking Arduino pin 29 and blinking it every 500ms. I then built the firmware manually with make uf2 EXTRA_FLAGS="-DOPK_PWR_SWITCH=1", flashed my NRF52, and confirmed that the Steam Controller was working. I then powered off the machine, waited 5 seconds, and pressed the Steam Controller power button. After a second, a red LED lit up on the front side of the board, but the LED I hooked up doesn't seem to ever light up. I haven't even tried to build the circuit yet, I was hoping to confirm the LED on pin 29 turned on before going any further.

Is anyone successfully using this so far? Am I missing something dumb here?

Thank you!

Originally created by @sponge on GitHub (Sep 8, 2026). Original GitHub issue: https://github.com/safijari/openpuck/issues/281 Hello! I'm trying to get the new cold boot feature to work. I verified I'm on the right pin by blinking Arduino pin 29 and blinking it every 500ms. I then built the firmware manually with `make uf2 EXTRA_FLAGS="-DOPK_PWR_SWITCH=1"`, flashed my NRF52, and confirmed that the Steam Controller was working. I then powered off the machine, waited 5 seconds, and pressed the Steam Controller power button. After a second, a red LED lit up on the front side of the board, but the LED I hooked up doesn't seem to ever light up. I haven't even tried to build the circuit yet, I was hoping to confirm the LED on pin 29 turned on before going any further. Is anyone successfully using this so far? Am I missing something dumb here? Thank you!

roman commented 2026-10-22 05:05:16 +00:00

Author

Owner

Copy link

@safijari commented on GitHub (Sep 8, 2026):

Paging @katzmatt

<!-- gh-comment-id:5586660975 --> @safijari commented on GitHub (Sep 8, 2026): Paging @katzmatt

roman commented 2026-10-22 05:05:17 +00:00

Author

Owner

Copy link

@safijari commented on GitHub (Sep 8, 2026):

Apologies, I had removed it because I thought it was just for testing (which I suppose it was).

<!-- gh-comment-id:5587221656 --> @safijari commented on GitHub (Sep 8, 2026): Apologies, I had removed it because I thought it was just for testing (which I suppose it was).

roman commented 2026-10-22 05:05:18 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 8, 2026):

so if the NRF board is always receiving power, you should be able to press, to wake and connect the controller, and then a short press on the steam button to fire the power signal and blink the LED at the same time

if you've confirmed the LED works on the right pin, then it should be fine?

<!-- gh-comment-id:5587393142 --> @katzmatt commented on GitHub (Sep 8, 2026): so if the NRF board is always receiving power, you should be able to press, to wake and connect the controller, and then a short press on the steam button to fire the power signal and blink the LED at the same time if you've confirmed the LED works on the right pin, then it should be fine?

roman commented 2026-10-22 05:05:19 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 8, 2026):

admittedly when I was building this on my own, I omitted the need for the extra flag, and ran with it "on by default"
for giggles, can you comment out
lines 140 and 142 to make sure it builds without the flag?
github.com/safijari/openpuck@29f4d1e8b8/OpenPuck/OpenPuck.ino (L140)

<!-- gh-comment-id:5587516364 --> @katzmatt commented on GitHub (Sep 8, 2026): admittedly when I was building this on my own, I omitted the need for the extra flag, and ran with it "on by default" for giggles, can you comment out lines 140 and 142 to make sure it builds without the flag? https://github.com/safijari/openpuck/blob/29f4d1e8b85c0a7c19e0c8b977a1a56a2c42ea6d/OpenPuck/OpenPuck.ino#L140

roman commented 2026-10-22 05:05:20 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 8, 2026):

Apologies, I had removed it because I thought it was just for testing (which I suppose it was).

it was, its not STRICTLY needed
different manufacturers will put different silkscreen labels on the board that could be wildly different from the actual pins on the chip
so I found it helpful like what Sponge has done, is just blink the pin and see if its the right one

<!-- gh-comment-id:5587555032 --> @katzmatt commented on GitHub (Sep 8, 2026): > Apologies, I had removed it because I thought it was just for testing (which I suppose it was). it was, its not STRICTLY needed different manufacturers will put different silkscreen labels on the board that could be wildly different from the actual pins on the chip so I found it helpful like what Sponge has done, is just blink the pin and see if its the right one

roman commented 2026-10-22 05:05:20 +00:00

Author

Owner

Copy link

@sponge commented on GitHub (Sep 8, 2026):

No change commenting those two lines. Is there any sort of logging available that I can add into that section with and see if it's actually hitting that code?

The only other difference I notice is that the red LED on the front comes on when I power on the controller while the PC is off. Is whatever triggers that unrelated to the coldboot?

<!-- gh-comment-id:5587660731 --> @sponge commented on GitHub (Sep 8, 2026): No change commenting those two lines. Is there any sort of logging available that I can add into that section with and see if it's actually hitting that code? The only other difference I notice is that the red LED on the front comes on when I power on the controller while the PC is off. Is whatever triggers that unrelated to the coldboot?

roman commented 2026-10-22 05:05:21 +00:00

Author

Owner

Copy link

@sponge commented on GitHub (Sep 8, 2026):

Tried getting rid of the other ifdef for OPK_PWR_SWITCH around the task function and no change. Changed version.h to make sure I was indeed running the right firmware, and saw the change reflected there, too.

<!-- gh-comment-id:5587935660 --> @sponge commented on GitHub (Sep 8, 2026): Tried getting rid of the other ifdef for OPK_PWR_SWITCH around the task function and no change. Changed version.h to make sure I was indeed running the right firmware, and saw the change reflected there, too.

roman commented 2026-10-22 05:05:22 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 8, 2026):

nothing that ive added interferes with the red light AFAIK

can you paste your test blink sketch?

also do you have a link to the board you are using?

<!-- gh-comment-id:5589405079 --> @katzmatt commented on GitHub (Sep 8, 2026): nothing that ive added interferes with the red light AFAIK can you paste your test blink sketch? also do you have a link to the board you are using?

roman commented 2026-10-22 05:05:22 +00:00

Author

Owner

Copy link

@sponge commented on GitHub (Sep 8, 2026):

Pretty straightforward:

void setup() {
  pinMode(29, OUTPUT);
}

void loop() {
  digitalWrite(29, HIGH);
  delay(500);
  digitalWrite(29, LOW);
  delay(500);
}

Will try tossing this into a couple of the functions and see if it is at least hitting that code there.

edit:

void pwrSwitchInit()
{
	pinMode(PWR_SWITCH_PIN, OUTPUT);
	digitalWrite(PWR_SWITCH_PIN, PWR_SWITCH_RELEASED);

	digitalWrite(PWR_SWITCH_PIN, HIGH);
	delay(1000);
	digitalWrite(PWR_SWITCH_PIN, LOW);
}

static void firePulse()
{
	digitalWrite(PWR_SWITCH_PIN, PWR_SWITCH_ACTIVE);
	s_pulseActive = true;
	s_pulseStartMs = millis();
	s_lastFireMs = s_pulseStartMs;
	s_everFired = true;
}

void pwrSwitchTask()
{

	digitalWrite(PWR_SWITCH_PIN, HIGH);
	delay(100);
	digitalWrite(PWR_SWITCH_PIN, LOW);
	delay(100);
	digitalWrite(PWR_SWITCH_PIN, HIGH);
	delay(100);
	digitalWrite(PWR_SWITCH_PIN, LOW);

...

Oddly enough, I'm never getting any blink here, either a long one at startup or the short ones at the start of the task. It did seem to break firmware uploading through the web UI, which makes sense given the delays are probably way slowing down the main loop. Just swapped over back to the blink sketch and confirmed that still worked.

Using this board: https://www.amazon.com/dp/B0DCZJKYL1

Here's a photo of the underside of the board, blinking on pin 29 using my sketch:

I did originally try using the pin next to GND, the one labeled 017, as was shown in the original pic but that one didn't work.

<!-- gh-comment-id:5589847743 --> @sponge commented on GitHub (Sep 8, 2026): Pretty straightforward: ``` void setup() { pinMode(29, OUTPUT); } void loop() { digitalWrite(29, HIGH); delay(500); digitalWrite(29, LOW); delay(500); } ``` Will try tossing this into a couple of the functions and see if it is at least hitting that code there. edit: ```c void pwrSwitchInit() { pinMode(PWR_SWITCH_PIN, OUTPUT); digitalWrite(PWR_SWITCH_PIN, PWR_SWITCH_RELEASED); digitalWrite(PWR_SWITCH_PIN, HIGH); delay(1000); digitalWrite(PWR_SWITCH_PIN, LOW); } static void firePulse() { digitalWrite(PWR_SWITCH_PIN, PWR_SWITCH_ACTIVE); s_pulseActive = true; s_pulseStartMs = millis(); s_lastFireMs = s_pulseStartMs; s_everFired = true; } void pwrSwitchTask() { digitalWrite(PWR_SWITCH_PIN, HIGH); delay(100); digitalWrite(PWR_SWITCH_PIN, LOW); delay(100); digitalWrite(PWR_SWITCH_PIN, HIGH); delay(100); digitalWrite(PWR_SWITCH_PIN, LOW); ... ``` Oddly enough, I'm never getting any blink here, either a long one at startup or the short ones at the start of the task. It did seem to break firmware uploading through the web UI, which makes sense given the delays are probably way slowing down the main loop. Just swapped over back to the blink sketch and confirmed that still worked. Using this board: https://www.amazon.com/dp/B0DCZJKYL1 Here's a photo of the underside of the board, blinking on pin 29 using my sketch: <img width="1920" height="1440" alt="Image" src="https://github.com/user-attachments/assets/553af1e7-b35c-4b90-83d2-f52447d73dbf" /> I did originally try using the pin next to GND, the one labeled 017, as was shown in the original pic but that one didn't work.

roman commented 2026-10-22 05:05:23 +00:00

Author

Owner

Copy link

@sponge commented on GitHub (Sep 8, 2026):

Doing a little more digging, using this at the top of OpenPuck's setup() still doesn't work:

void setup()
{
	pinMode(29, OUTPUT);
	digitalWrite(29, HIGH);
	delay(1000);
	digitalWrite(29, LOW);
	delay(5000);
...

The firmware is definitely being loaded because it now takes 5 seconds for the OpenPuck Config web app to pick up that it is connected, and my version.h is being used.

The only other difference here must be in how it is being built: I am using the Arduino IDE for the blink sketch, however I'm building OpenPuck via arduino-cli, running on Windows/WSL so I can use the Makefile to generate the UF2 as documented here

When using the IDE, I'm using it directly in Windows, and am setting the device to "Nordic nRF52840 DK" set to COM6. I'm guessing I need to make it with another board definition as mentioned here make build FQBN=adafruit:nrf52:somethingelse # a different nRF52840 board

<!-- gh-comment-id:5593565598 --> @sponge commented on GitHub (Sep 8, 2026): Doing a little more digging, using this at the top of OpenPuck's setup() _still_ doesn't work: ```c void setup() { pinMode(29, OUTPUT); digitalWrite(29, HIGH); delay(1000); digitalWrite(29, LOW); delay(5000); ... ``` The firmware is definitely being loaded because it now takes 5 seconds for the OpenPuck Config web app to pick up that it is connected, and my version.h is being used. The only other difference here must be in how it is being built: I am using the Arduino IDE for the blink sketch, however I'm building OpenPuck via arduino-cli, running on Windows/WSL so I can use the Makefile to generate the UF2 [as documented here](https://github.com/safijari/openpuck/blob/main/docs/BUILD_AND_DEPLOY.md#3-install-the-board-core) When using the IDE, I'm using it directly in Windows, and am setting the device to "Nordic nRF52840 DK" set to COM6. I'm guessing I need to make it with another board definition as mentioned here `make build FQBN=adafruit:nrf52:somethingelse # a different nRF52840 board`

roman commented 2026-10-22 05:05:24 +00:00

Author

Owner

Copy link

@sponge commented on GitHub (Sep 9, 2026):

Alright, a little progress:

1. When I switch Arduino IDE back to the Adafruit Feather NRF52480 Express, the LED on my minimal blink no longer works until I move the physical LED back to the pin labeled 017 on the silkscreen, so basically an identical setup to the config shown in the coldboot setup photo. The above code added in OpenPuck's setup now works: every time I power on the board, the LED lights up for 1 second, turns off, and it continues to start up. If I add an LED strobe in pwrSwitchTask, the led now strobes properly. Partly user error here, but this is compounded by...

2. The LED still doesn't pulse when I power off the PC and then hit the power button on the Steam controller. When I add this code into the task:

	if (hostOff) {
		digitalWrite(29, HIGH);
		delay(100);
		digitalWrite(29, LOW);
		delay(100);
		digitalWrite(29, HIGH);
		delay(100);
		digitalWrite(29, LOW);
	}

the LED never blinks, implying that hostOff is never set to true. If I hardcode that if to true, the light blinks. Unfortunately, a bit stuck at this point as I'm not sure how to debug this from here since I don't think I can print to anything.

<!-- gh-comment-id:5594095569 --> @sponge commented on GitHub (Sep 9, 2026): Alright, a little progress: 1. When I switch Arduino IDE back to the Adafruit Feather NRF52480 Express, the LED on my minimal blink no longer works until I move the physical LED back to the pin labeled 017 on the silkscreen, so basically an identical setup to the config shown in the coldboot setup photo. The above code added in OpenPuck's setup now works: every time I power on the board, the LED lights up for 1 second, turns off, and it continues to start up. If I add an LED strobe in pwrSwitchTask, the led now strobes properly. Partly user error here, but this is compounded by... 2. The LED still doesn't pulse when I power off the PC and then hit the power button on the Steam controller. When I add this code into the task: ```c if (hostOff) { digitalWrite(29, HIGH); delay(100); digitalWrite(29, LOW); delay(100); digitalWrite(29, HIGH); delay(100); digitalWrite(29, LOW); } ``` the LED never blinks, implying that hostOff is never set to true. If I hardcode that if to true, the light blinks. Unfortunately, a bit stuck at this point as I'm not sure how to debug this from here since I don't think I can print to anything.

roman commented 2026-10-22 05:05:25 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 9, 2026):

interesting, yes, your board and my board seem to be the same Nice! Nano as mine, so the Pin 017 should be the correct one.

as for not firing, how is the board connected to your computer?

hostOff is set based on USBdevice.mounted() reading false.

for diagnostics, can you plug the board into a USB wall plug that just has power? if the controller is able to connect and the light blinks, then it means something on your machine is mounting the device in the off state

I have my board connected to one of the internal USB2.0 headers with a small hub, im wondering if that makes a difference now.

<!-- gh-comment-id:5602630779 --> @katzmatt commented on GitHub (Sep 9, 2026): interesting, yes, your board and my board seem to be the same Nice! Nano as mine, so the Pin 017 should be the correct one. as for not firing, how is the board connected to your computer? hostOff is set based on USBdevice.mounted() reading false. for diagnostics, can you plug the board into a USB wall plug that just has power? if the controller is able to connect and the light blinks, then it means something on your machine is mounting the device in the off state I have my board connected to one of the internal USB2.0 headers with a small hub, im wondering if that makes a difference now.

roman commented 2026-10-22 05:05:26 +00:00

Author

Owner

Copy link

@sponge commented on GitHub (Sep 9, 2026):

Looks like my blink fires when plugged into a wall outlet. I was originally connected to a USB hub, but moved it directly into the PC thinking that might be an issue. Looks like all the USB ports on the back of my PC are USB3, so can't test a USB 2.0 port.

The end goal is to shove this thing into a BC-250, so I might just pull that out and try my flashing hostOff test on that machine since that will be its final home. While it certainly won't help anyone who comes afterward looking at this thread, at least it'll solve my issue!

<!-- gh-comment-id:5604622185 --> @sponge commented on GitHub (Sep 9, 2026): Looks like my blink fires when plugged into a wall outlet. I was originally connected to a USB hub, but moved it directly into the PC thinking that might be an issue. Looks like all the USB ports on the back of my PC are USB3, so can't test a USB 2.0 port. The end goal is to shove this thing into a [BC-250](https://bc250.info), so I might just pull that out and try my flashing hostOff test on that machine since that will be its final home. While it certainly won't help anyone who comes afterward looking at this thread, at least it'll solve my issue!

roman commented 2026-10-22 05:05:27 +00:00

Author

Owner

Copy link

@sponge commented on GitHub (Sep 9, 2026):

Looks like it's working on the BC-250. There was one other piece of user error, I didn't realize that you needed an additional button press to trigger the power on besides the controller power on. I thought the controller connecting to the puck would be enough to trigger the power on, similar to how it works on the Switch. It'd be nice if the pulse could be fired when a controller successfully connects instead of requiring that extra button press. Not sure how feasible that is, though.

I did go back and double check, and the lack of an extra Steam button press is not what was causing my issue, the LED still never turns on. I suspected this would be the case after verifying hostOff doesn't get set to true, but just wanted to verify it. I'm probably good here, but without a great resolution for why it isn't working on my main PC. Happy to poke around with my second ProMicro, but I'm probably going to finish this up and get it integrated into the case.

<!-- gh-comment-id:5604839448 --> @sponge commented on GitHub (Sep 9, 2026): Looks like it's working on the BC-250. There was one other piece of user error, I didn't realize that you needed an additional button press to trigger the power on besides the controller power on. I thought the controller connecting to the puck would be enough to trigger the power on, similar to how it works on the Switch. It'd be nice if the pulse could be fired when a controller successfully connects instead of requiring that extra button press. Not sure how feasible that is, though. I did go back and double check, and the lack of an extra Steam button press is not what was causing my issue, the LED still never turns on. I suspected this would be the case after verifying hostOff doesn't get set to true, but just wanted to verify it. I'm probably good here, but without a great resolution for why it isn't working on my main PC. Happy to poke around with my second ProMicro, but I'm probably going to finish this up and get it integrated into the case.

roman commented 2026-10-22 05:05:27 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 9, 2026):

ok! im happy it worked with the BC250 ill see about updating the documentation to more explicitly saying "must press TWICE"

im very curious if a particular port is attempting to mount the device even with the mobo being "Off" which is very curious
if you do mess around more with it, try other USB ports and see what happens

<!-- gh-comment-id:5609363106 --> @katzmatt commented on GitHub (Sep 9, 2026): ok! im happy it worked with the BC250 ill see about updating the documentation to more explicitly saying "must press TWICE" im very curious if a particular port is attempting to mount the device even with the mobo being "Off" which is very curious if you do mess around more with it, try other USB ports and see what happens

roman commented 2026-10-22 05:05:28 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 9, 2026):

@safijari may I edit the Wiki page to clear up confusion?

<!-- gh-comment-id:5609400802 --> @katzmatt commented on GitHub (Sep 9, 2026): @safijari may I edit the Wiki page to clear up confusion?

roman commented 2026-10-22 05:05:29 +00:00

Author

Owner

Copy link

@sponge commented on GitHub (Sep 10, 2026):

Bad news from the BC-250 front, for me at least, I'm having to power cycle before power on works again. I don't have my debugging bits in there (and now its a pita to access since its inside the case I printed) but it looks like it only works for the first boot. Shutting down the machine after that, it doesn't seem to work a second time until I power cycle the PSU to kill the USB connection. I'm using one of the USB2.0 ports, not sure if that matters at all.

<!-- gh-comment-id:5623337163 --> @sponge commented on GitHub (Sep 10, 2026): Bad news from the BC-250 front, for me at least, I'm having to power cycle before power on works again. I don't have my debugging bits in there (and now its a pita to access since its inside the case I printed) but it looks like it only works for the first boot. Shutting down the machine after that, it doesn't seem to work a second time until I power cycle the PSU to kill the USB connection. I'm using one of the USB2.0 ports, not sure if that matters at all.

roman commented 2026-10-22 05:05:30 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 10, 2026):

Hmm.
Do you by chance have a USB hub you could try running it through?

My testing setup was via a hub, I'll need to pull mine apart and see if the behavior mimics your setup when it's directly connected to the mobo

When merging my fork, it was brought up by another contributor to utilize the power LED as a sensor input to validate ON/OFF state of the motherboard

It's becoming clearer that it may be necessary to implement instead of using USB.mounted() as the indicator.
It wouldn't be hard software wise, plus an extra wire to solder in.
Doing it this way would bypass the whole issue we are facing.

On a side note, the BC250, does it have a standard front panel port with button and power LED headers?

<!-- gh-comment-id:5624503037 --> @katzmatt commented on GitHub (Sep 10, 2026): Hmm. Do you by chance have a USB hub you could try running it through? My testing setup was via a hub, I'll need to pull mine apart and see if the behavior mimics your setup when it's directly connected to the mobo When merging my fork, it was brought up by another contributor to utilize the power LED as a sensor input to validate ON/OFF state of the motherboard It's becoming clearer that it may be necessary to implement instead of using USB.mounted() as the indicator. It wouldn't be hard software wise, plus an extra wire to solder in. Doing it this way would bypass the whole issue we are facing. On a side note, the BC250, does it have a standard front panel port with button and power LED headers?

roman commented 2026-10-22 05:05:31 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 10, 2026):

Also just want to mention, I want to thank you for going back and forth and sharing your progress in trying out my feature.

Despite doing electronics and software projects for many years this is my first contribution to an open source project.

And I appreciate the constructive feedback and persistence.

<!-- gh-comment-id:5624608029 --> @katzmatt commented on GitHub (Sep 10, 2026): Also just want to mention, I want to thank you for going back and forth and sharing your progress in trying out my feature. Despite doing electronics and software projects for **many** years this is my first contribution to an open source project. And I appreciate the constructive feedback and persistence.

roman commented 2026-10-22 05:05:32 +00:00

Author

Owner

Copy link

@sponge commented on GitHub (Sep 12, 2026):

No problem, sorry I couldn't be more help!

I'll have to try and see what USB hubs I have around. I didn't notice a difference between hub and not hub on my desktop that seemingly never unmounted. I'm going to also poke around at BIOS settings for legacy mouse/keyboard types of options to see if that makes a difference. I didn't try a hub on the BC-250 yet.

(Unfortunately I've been getting some controller drops since trying to use OpenPuck but I suspect it's a signal issue, I had the same issue with the official puck until I slid it up further toward the front of my entertainment center. Bit harder to do when its integrated in the case though!)

There are no headers on the BC-250 except for a CPU fan. I had to solder directly to a point on the board to get access to the power switch, and there were tons of pins connected to ground. I suspect I'd have to do something similar to get the power LED. I did a little research into this since I don't know anything about USB and everything seems to recommend using mounted, so this definitely seems like it's supposed to work. This is the reality of any widely adopted standard I suppose. I can't imagine there's any traffic coming from the host to the microcontroller that would cease if the host is off, is there?

<!-- gh-comment-id:5647423772 --> @sponge commented on GitHub (Sep 12, 2026): No problem, sorry I couldn't be more help! I'll have to try and see what USB hubs I have around. I didn't notice a difference between hub and not hub on my desktop that seemingly never unmounted. I'm going to also poke around at BIOS settings for legacy mouse/keyboard types of options to see if that makes a difference. I didn't try a hub on the BC-250 yet. (Unfortunately I've been getting some controller drops since trying to use OpenPuck but I suspect it's a signal issue, I had the same issue with the official puck until I slid it up further toward the front of my entertainment center. Bit harder to do when its integrated in the case though!) There are no headers on the BC-250 except for a CPU fan. I had to solder directly to a point on the board to get access to the power switch, and there were tons of pins connected to ground. I suspect I'd have to do something similar to get the power LED. I did a little research into this since I don't know anything about USB and everything seems to recommend using mounted, so this definitely seems like it's *supposed* to work. This is the reality of any widely adopted standard I suppose. I can't imagine there's any traffic coming from the host to the microcontroller that would cease if the host is off, is there?

roman commented 2026-10-22 05:05:33 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 19, 2026):

@Nikoroq is experiencing the same issue of device not unmounting after first trigger and shutdown.
can you provide more details about your hardware system and how the device is plugged into the mobo?

I believe that will be solved with LED indicator feedback as well

I will have some time over the next week/weekend (hopefully) to wire up a working solution and update my fork

I will comment here when the fork is updated for testing.

once @sponge and @Nikoroq can verify the issue is fixed, ill open another PR to merge back to main

<!-- gh-comment-id:5743671604 --> @katzmatt commented on GitHub (Sep 19, 2026): @Nikoroq is experiencing the same issue of device not unmounting after first trigger and shutdown. can you provide more details about your hardware system and how the device is plugged into the mobo? I believe that will be solved with LED indicator feedback as well I will have some time over the next week/weekend (hopefully) to wire up a working solution and update my fork I will comment here when the fork is updated for testing. once @sponge and @Nikoroq can verify the issue is fixed, ill open another PR to merge back to main

roman commented 2026-10-22 05:05:33 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 19, 2026):

additional question for @sponge, you mentioned the BS250 has no power indicator LED.
does this hook up to a standard ATX power supply?
does the PSU require manual activation for power on? or can the BS250 activate the PSU?

(my thinking is to find a spot to pull some kind of "board on" voltage, be it 12v 5v or 3.3v doesn't matter as long as its high when the board is actually on)

<!-- gh-comment-id:5743711344 --> @katzmatt commented on GitHub (Sep 19, 2026): additional question for @sponge, you mentioned the BS250 has no power indicator LED. does this hook up to a standard ATX power supply? does the PSU require manual activation for power on? or can the BS250 activate the PSU? (my thinking is to find a spot to pull some kind of "board on" voltage, be it 12v 5v or 3.3v doesn't matter as long as its high when the board is actually on)

roman commented 2026-10-22 05:05:34 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Sep 20, 2026):

@katzmatt

1. Mobo: Gigabyte X870I Pro Ice rev 1.1.
2. The NRF52840 board - bought exactly from the listing by the link on the OpenPuck main (https://www.amazon.com/dp/B0GSZ7FD6T).
3. Plugged via the inside motherboard header. (USB)
4. LED indicator as in update for existing LEDs of NRF52840 (red/blue) or that LED of yours soldered to the board? I don't have the latter, too bulky for my exact setup.
5. Following the question you asked of sponge: Do you think such a solution might be reliable? When ErP is turned off it sends some power, might be a hassle to differentiate which exact power is "board on".

I really really think it is some kind of oversight, since, when the system is shut, controller reacts as it should: it turns off.
The only match with sponge I see - we both on Linux. BC-250 (not BS250) that sponge uses - is a scribed off PlayStation 5 motherboard, repurposed to be a PC. The thing is, it can't work anywhere but on Linux. Maybe NRF52840 reacts differently when plugged to a different OS (for example, default Windows behavior on shut down - deep hibernation, not shut down, which is not the case for Linux)

<!-- gh-comment-id:5750333581 --> @Nikoroq commented on GitHub (Sep 20, 2026): @katzmatt 1. Mobo: Gigabyte X870I Pro Ice rev 1.1. 2. The NRF52840 board - bought exactly from the listing by the link on the OpenPuck main (https://www.amazon.com/dp/B0GSZ7FD6T). 3. Plugged via the inside motherboard header. (USB) 4. LED indicator as in update for existing LEDs of NRF52840 (red/blue) or that LED of yours soldered to the board? I don't have the latter, too bulky for my exact setup. 5. Following the question you asked of sponge: Do you think such a solution might be reliable? When ErP is turned off it sends some power, might be a hassle to differentiate which exact power is "board on". I really really think it is some kind of oversight, since, when the system is shut, controller reacts as it should: it turns off. The only match with sponge I see - we both on Linux. BC-250 (not BS250) that sponge uses - is a scribed off PlayStation 5 motherboard, repurposed to be a PC. The thing is, it can't work anywhere but on Linux. Maybe NRF52840 reacts differently when plugged to a different OS (for example, default Windows behavior on shut down - deep hibernation, not shut down, which is not the case for Linux)

roman commented 2026-10-22 05:05:34 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Sep 22, 2026):

If I could be of any help, I will answer in a short notice.

<!-- gh-comment-id:5780604985 --> @Nikoroq commented on GitHub (Sep 22, 2026): If I could be of any help, I will answer in a short notice.

roman commented 2026-10-22 05:05:35 +00:00

Author

Owner

Copy link

@sponge commented on GitHub (Sep 22, 2026):

I'm using a I think 300W FlexATX PSU. It has an ATX connector that I had to jump in order to boot. There's just a hard power switch now to power it on. There's then a power button on the backplate. The board itself only uses an 8 pin PCI-E plug.

Just to note, there is a power LED, it's just that it doesn't have the standard header for power switch and LED hookups, they're all hardwired. I'll just have to solder a wire to the back of the board. The power LED sense should work just fine for these boards, you'll just need to solder directly to the correct leg on the other side of the board, which is not a big deal since you'll need to do that already for the power switch.

For what it's worth, my main PC is running Windows and that one never unmounts, so I don't think it's an OS thing.

<!-- gh-comment-id:5785566160 --> @sponge commented on GitHub (Sep 22, 2026): I'm using a I think 300W FlexATX PSU. It has an ATX connector that I had to jump in order to boot. There's just a hard power switch now to power it on. There's then a power button on the backplate. The board itself only uses an 8 pin PCI-E plug. Just to note, there **is** a power LED, it's just that it doesn't have the standard header for power switch and LED hookups, they're all hardwired. I'll just have to solder a wire to the back of the board. The power LED sense should work just fine for these boards, you'll just need to solder directly to the correct leg on the other side of the board, which is not a big deal since you'll need to do that already for the power switch. For what it's worth, my main PC is running Windows and that one **never** unmounts, so I don't think it's an OS thing.

roman commented 2026-10-22 05:05:36 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 23, 2026):

Alright, all of this is good to know, thank you both, I shouuuuuuld have some time Friday/Saturday to work on this 

<!-- gh-comment-id:5787980306 --> @katzmatt commented on GitHub (Sep 23, 2026): Alright, all of this is good to know, thank you both, I shouuuuuuld have some time Friday/Saturday to work on this 

roman commented 2026-10-22 05:05:37 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 26, 2026):

Alrighty! made a lot of progress here with using a voltage divider and an analog pin as a sense line on the boards power LED

things seem to now be working reliably on my system

when you can, please try out my changes found at https://github.com/katzmatt/openpuck-ColdBoot/
and let me know if that firmware and wiring works for you, and then ill add another PR to main

last Q for @safijari may I have Wiki edit access to change the instructions and wiring diagrams for the Coldboot section?

this is EASILY adapted to feed off the BS250's cpu fan header (to sense board ON) by changing the two resistors used in the voltage divider

<!-- gh-comment-id:5842137023 --> @katzmatt commented on GitHub (Sep 26, 2026): Alrighty! made a lot of progress here with using a voltage divider and an analog pin as a sense line on the boards power LED things seem to now be working reliably on my system when you can, please try out my changes found at https://github.com/katzmatt/openpuck-ColdBoot/ and let me know if that firmware and wiring works for you, and then ill add another PR to main last Q for @safijari may I have Wiki edit access to change the instructions and wiring diagrams for the Coldboot section? this is **EASILY** adapted to feed off the BS250's cpu fan header (to sense board ON) by changing the two resistors used in the voltage divider

roman commented 2026-10-22 05:05:38 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 26, 2026):

ok the wiki page on my fork still needs some edits to make sense rather than ai slop (please excuse for now until I clean it up)
and feel free to ask questions here, ill answer as best I can

<!-- gh-comment-id:5842323718 --> @katzmatt commented on GitHub (Sep 26, 2026): ok the wiki page on my fork still needs some edits to make sense rather than ai slop (please excuse for now until I clean it up) and feel free to ask questions here, ill answer as best I can

roman commented 2026-10-22 05:05:38 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Sep 26, 2026):

Description is a bit confusing. Should I just build new firmware, upload it to the board and test it right away? Or should I wire/solder anything on top of existing setup?

<!-- gh-comment-id:5843967232 --> @Nikoroq commented on GitHub (Sep 26, 2026): Description is a bit confusing. Should I just build new firmware, upload it to the board and test it right away? Or should I wire/solder anything on top of existing setup?

roman commented 2026-10-22 05:05:39 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 26, 2026):

https://github.com/katzmatt/openpuck-ColdBoot/wiki/How-to-wire-up-an-NRF52-board-for-cold-boot
has been updated for clarity and sense
run a build from my fork with make uf2 EXTRA_FLAGS="-DOPK_PWR_SWITCH=1 -DPWR_SENSE_ACTIVE_HIGH=0 -DPWR_SENSE_THRESHOLD=730"
(or change the values depending on your situation)

<!-- gh-comment-id:5848951857 --> @katzmatt commented on GitHub (Sep 26, 2026): https://github.com/katzmatt/openpuck-ColdBoot/wiki/How-to-wire-up-an-NRF52-board-for-cold-boot has been updated for clarity and sense run a build from my fork with `make uf2 EXTRA_FLAGS="-DOPK_PWR_SWITCH=1 -DPWR_SENSE_ACTIVE_HIGH=0 -DPWR_SENSE_THRESHOLD=730" ` (or change the values depending on your situation)

roman commented 2026-10-22 05:05:40 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Sep 26, 2026):

Thanks for clarification. Will ask something else before tests

1. 2 resistors needed for the default setup with PWR LED+ at 5V, if I read the table correctly, one should be 10k resistor (that would go between pin (029 in your case) and PWR LED+), and the second one is 20k resistor (would go from 029 pin to GND on the same NRF52840), correct?
2. I know it is kind of silly, but would you mind to show the exact wiring path, maybe even marking them using paint, if possible.

I have a hard time reading tech drawing, but if I understand it correctly: 7th pin of the NRF52840 (029 in your case) should be soldered to the GND (of NRF52840) by a 20k resistor, and the cable that would go to PWR LED+ should be soldered to 029 pin via 10k resistor, not in the middle (10k+10k) of two resistors... correct? (Like 029 pin -> resistor (10k one) -> PWR LED+ and not inbetween of R2 -> 10k resistor -> PWR LED+)

If so, confirm. If not, please, do some art for people that aren't too technical... thanks!

3. I have multimeter, and before using it, I want to clarify: in DC volts mode, I should tap red wire to the tap point (either PWR LED+ or something else) and the black wire to the ground on the motherboard?
   If so, which point would serve as the ground on the motherboard for that test?
   I assume, PC needed to be plugged into the wall and PSU is at a ready state, even if I measure voltage in PC off state. Correct?

Excuse my ignorance, I'm not highly experienced here, at all

<!-- gh-comment-id:5850062526 --> @Nikoroq commented on GitHub (Sep 26, 2026): Thanks for clarification. Will ask something else before tests 1. 2 resistors needed for the default setup with PWR LED+ at 5V, if I read the table correctly, one should be 10k resistor (that would go between pin (029 in your case) and PWR LED+), and the second one is 20k resistor (would go from 029 pin to GND on the same NRF52840), correct? 2. I know it is kind of silly, but would you mind to show the exact wiring path, maybe even marking them using paint, if possible. I have a hard time reading tech drawing, but if I understand it correctly: 7th pin of the NRF52840 (029 in your case) should be soldered to the GND (of NRF52840) by a 20k resistor, and the cable that would go to PWR LED+ should be soldered to 029 pin via 10k resistor, not in the middle (10k+10k) of two resistors... correct? (Like 029 pin -> resistor (10k one) -> PWR LED+ and not *inbetween of R2* -> 10k resistor -> PWR LED+) If so, confirm. If not, please, do some art for people that aren't too technical... thanks! 3. I have multimeter, and before using it, I want to clarify: in DC volts mode, I should tap red wire to the tap point (either PWR LED+ or something else) and the black wire to the ground on the motherboard? If so, which point would serve as the ground on the motherboard for that test? I assume, PC needed to be plugged into the wall and PSU is at a ready state, even if I measure voltage in PC off state. Correct? Excuse my ignorance, I'm not highly experienced here, at all

roman commented 2026-10-22 05:05:41 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 26, 2026):

sure sure

1. yes you got it right!
   so pin029 is in the middle of the two resistors (also values don't have to be precise, approximate is ok and combining to equal in series is ok)
   GND > 20k > Pin 029 > 10k > PwrLED+

Check out some of the photos at the bottom, I had to use 2 10k in series to add up to 20k , I just wired those underneath my board between GND and 029. then a 10K in series on the longer wire that touches PWLED+

2. I can if you still need further clarification

3. yes, DC mode, Red to probe the voltage source and Black to any bit of metal on the case, (screws, outer metal of connectors, etc.)

Measure when the PC is turned off normally (OS is OFF) and measure after pressing the power button and things are running

<!-- gh-comment-id:5850279235 --> @katzmatt commented on GitHub (Sep 26, 2026): sure sure 1. yes you got it right! so pin029 is in the middle of the two resistors (also values don't have to be precise, approximate is ok and combining to equal in series is ok) GND > 20k > Pin 029 > 10k > PwrLED+ Check out some of the photos at the bottom, I had to use 2 10k in series to add up to 20k , I just wired those underneath my board between GND and 029. then a 10K in series on the longer wire that touches PWLED+ 2. I can if you still need further clarification 3. yes, DC mode, Red to probe the voltage source and Black to any bit of metal on the case, (screws, outer metal of connectors, etc.) Measure when the PC is turned off normally (OS is OFF) and measure after pressing the power button and things are running

roman commented 2026-10-22 05:05:41 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Sep 27, 2026):

I wonder though, how 20K resistor would contribute if it will be soldered to the ground after the connection from PWR LED+ to 029... I know there's a science behind it, but I want to make sure I didn't get it wrong. 20K resistor, absolutely sure, goes directly from 029 to GND. Next, a single wire is soldered to pin 029 directly, goes to another resistor of 10k, connects to the PWR LED+

I'm ordering correct resistors as we speak, so please confirm the above is correct and I will report as soon as the order will arrive

<!-- gh-comment-id:5851656756 --> @Nikoroq commented on GitHub (Sep 27, 2026): I wonder though, how 20K resistor would contribute if it will be soldered to the ground after the connection from PWR LED+ to 029... I know there's a science behind it, but I want to make sure I didn't get it wrong. 20K resistor, absolutely sure, goes directly from 029 to GND. Next, a single wire is soldered to pin 029 directly, goes to another resistor of 10k, connects to the PWR LED+ I'm ordering correct resistors as we speak, so please confirm the above is correct and I will report as soon as the order will arrive

roman commented 2026-10-22 05:05:42 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 28, 2026):

so yes you got it correct,
you may find it cheaper to just get a small assortment box of resistors, but thats up 2 u

so the way a voltage divider works in simple terms is that the 2 resistors are dropping 100% of the voltage potential between source and ground.

imagine a really long resistor without any insulation. a long piece of wire. you have 5v on one end, and 0v on the other
if you measured anywhere in the middle with a probe, you would end up finding a voltage of somewhere BETWEEN 5v and 0v. the further towards one end you measure, the closer towards that voltage you would read

this is the same principal that a potentiometer works on, its just a variable resistor

because we know what our expected source is (3.3,5,12v) we can pre-determine what resistor combo to use to get to the sweet spot where the voltage is 3.3 or less (the amount the board is able to handle)

In theory, you could use any value of resistor for the total. but we use higher values to limit the overall current and not waste power (if it were too low it would make a lot of excess heat)

<!-- gh-comment-id:5870779284 --> @katzmatt commented on GitHub (Sep 28, 2026): so yes you got it correct, you may find it cheaper to just get a small assortment box of resistors, but thats up 2 u so the way a voltage divider works in simple terms is that the 2 resistors are dropping 100% of the voltage potential between source and ground. imagine a really long resistor without any insulation. a long piece of wire. you have 5v on one end, and 0v on the other if you measured anywhere in the middle with a probe, you would end up finding a voltage of somewhere BETWEEN 5v and 0v. the further towards one end you measure, the closer towards that voltage you would read this is the same principal that a potentiometer works on, its just a variable resistor <img height="1200" alt="Image" src="https://github.com/user-attachments/assets/95a6a166-f547-4383-a0c2-d474c36821bd" /> because we know what our expected source is (3.3,5,12v) we can pre-determine what resistor combo to use to get to the sweet spot where the voltage is 3.3 or less (the amount the board is able to handle) In theory, you could use any value of resistor for the total. but we use higher values to limit the overall current and not waste power (if it were too low it would make a lot of excess heat)

roman commented 2026-10-22 05:05:43 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Sep 28, 2026):

Oh, I get it now! So the resistor after the pin input, leading straight to the ground, exists just to equal the current to ground and to do so without too much heat. Neat!
Either way, resistors are on their way, will report as soon as feasibly possible.

<!-- gh-comment-id:5874479780 --> @Nikoroq commented on GitHub (Sep 28, 2026): Oh, I get it now! So the resistor after the pin input, leading straight to the ground, exists just to equal the current to ground and to do so without too much heat. Neat! Either way, resistors are on their way, will report as soon as feasibly possible.

roman commented 2026-10-22 05:05:44 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Sep 30, 2026):

I have news
It works
But I have to provide something: it was hard to figure out.
I'm not particularly bad at math, but the part that says

"in analogRead() counts (default 10-bit, 0–3.6V full-scale): round((V_pin_on + V_pin_off) / 2 / 3.6 * 1023)."

blew capacitor under my skull off
If not to AI that knows what analogRead() counts and round() - I wouldn't have figured it out.

Anyway, it went something like this:

1. I measured V_off as 5.1V and V_on as 3.866V
2. Which gives 3.4V and 2.577V respectively after being devided.
3. So after (3.4 + 2.577)/2 = 2.9885
4. and (2.9885/3.6)1023 = 849.23
5. I received PWR_SENSE_THRESHOLD=850 (I rounded it up to the higher value as you did, since after my calculations with your voltage you should've putted value that is ~1 point lower)
6. Since on my F_panel, PLED+ pin tap point, V_off > V_on - PWR_SENSE_ACTIVE_HUGH=0
7. After building .nf2 file from your fork, using parameters above, soldering (not, just smashed everything together with a lot of shrinking tubes) 20k resistor between the GND and 029pin of the NRF52840, and 10k resistor between the 029pin and PLED+ pin on the F_Panel header - I got everything working as expected.

First note: I accidentally plugged PSU power cable to the PSU during tests, while the NRF52840 been connected only by the 029 pin and 017 pin, but not plugged into USB-C (just NRF52840 off) - PC turned on by itself and turned itself off after a short while.

-Strange.

Second note: After turning PC on with a controller now, controller turns OFF during boot, somewhere in-between of displaying post screen. So the process of launching the PC now is [Turn controller on -> Press Steam button again to start PC -> wait until controller will turn itself off -> turn controller on again]

-Not critical, but not at all ideal, maybe it is a good thing to find a workaround for this as a main repo pull request for "ColdBoot upgrade" if you catch what I mean

<!-- gh-comment-id:5918395240 --> @Nikoroq commented on GitHub (Sep 30, 2026): I have news It works But I have to provide something: it was hard to figure out. I'm not particularly bad at math, but the part that says "in analogRead() counts (default 10-bit, 0–3.6V full-scale): round((V_pin_on + V_pin_off) / 2 / 3.6 * 1023)." blew capacitor under my skull off If not to AI that knows what analogRead() counts and round() - I wouldn't have figured it out. Anyway, it went something like this: 1. I measured V_off as 5.1V and V_on as 3.866V 2. Which gives 3.4V and 2.577V respectively after being devided. 3. So after (3.4 + 2.577)/2 = 2.9885 4. and (2.9885/3.6)1023 = 849.23 5. I received PWR_SENSE_THRESHOLD=850 (I rounded it up to the higher value as you did, since after my calculations with your voltage you should've putted value that is ~1 point lower) 6. Since on my F_panel, PLED+ pin tap point, V_off > V_on - PWR_SENSE_ACTIVE_HUGH=0 7. After building .nf2 file from your fork, using parameters above, soldering (not, just smashed everything together with a lot of shrinking tubes) 20k resistor between the GND and 029pin of the NRF52840, and 10k resistor between the 029pin and PLED+ pin on the F_Panel header - **I got everything working as expected.** First note: I accidentally plugged PSU power cable to the PSU during tests, while the NRF52840 been connected only by the 029 pin and 017 pin, but not plugged into USB-C (just NRF52840 off) - PC turned on by itself and turned itself off after a short while. -Strange. Second note: After turning PC on with a controller now, controller turns OFF during boot, somewhere in-between of displaying post screen. So the process of launching the PC now is [Turn controller on -> Press Steam button again to start PC -> wait until controller will turn itself off -> turn controller on again] -Not critical, but not at all ideal, maybe it is a good thing to find a workaround for this as a main repo pull request for "ColdBoot upgrade" if you catch what I mean

roman commented 2026-10-22 05:05:45 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 30, 2026):

HUZZAH!, im glad it works!!

I will do my best to simplify that math. I realize its much more confusing when not having The Computer do it

on your first note, yea that happened to me to, without a ground, the board will kinda just... float at whatever voltage is plugged in, if you've got 5v coming from your LED+ pin it will bring the transistor voltage up to the point where it transists and boots the computer! but in this case its still holding down the button, so the mobo will turn back off again.
with the USB plugged in first everything will work as expected

second note: ill have to see if there is some timeout on the board to edit. I haven't had this issue on mine, but yours might be booting slower. are you using an SSD for your OS?

im not sure what you mean with the last note of Coldboot upgrade?

<!-- gh-comment-id:5920212150 --> @katzmatt commented on GitHub (Sep 30, 2026): **HUZZAH!, im glad it works!!** I will do my best to simplify that math. I realize its much more confusing when not having The Computer do it on your first note, yea that happened to me to, without a ground, the board will kinda just... float at whatever voltage is plugged in, if you've got 5v coming from your LED+ pin it will bring the transistor voltage up to the point where it transists and boots the computer! but in this case its still holding down the button, so the mobo will turn back off again. with the USB plugged in first everything will work as expected second note: ill have to see if there is some timeout on the board to edit. I haven't had this issue on mine, but yours might be booting slower. are you using an SSD for your OS? im not sure what you mean with the last note of Coldboot upgrade?

roman commented 2026-10-22 05:05:46 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Sep 30, 2026):

do you mind if I use your math in the wiki as an example?

<!-- gh-comment-id:5920377340 --> @katzmatt commented on GitHub (Sep 30, 2026): do you mind if I use your math in the wiki as an example?

roman commented 2026-10-22 05:05:47 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Sep 30, 2026):

I absolutely don't, it is yours after all :)

Second note topic: yes, an SSD, one of the fastest ones of the PCIe 4.0. It maybe due to the fast boot option enabled, have to test it really. (maybe it re-enumerates USB during initialization which in turn makes openpuck to first lose enumerution for a split second, triggering shut down command. It is just a theory)

Coldboot upgrade - is just my title suggest for the next pull request that would not only add sense pin, but a "fix" for controller turning off if turned on too early during system startup (a downside of the original puck too btw)

<!-- gh-comment-id:5920537193 --> @Nikoroq commented on GitHub (Sep 30, 2026): I absolutely don't, it is yours after all :) Second note topic: yes, an SSD, one of the fastest ones of the PCIe 4.0. It maybe due to the fast boot option enabled, have to test it really. (maybe it re-enumerates USB during initialization which in turn makes openpuck to first lose enumerution for a split second, triggering shut down command. It is just a theory) Coldboot upgrade - is just my title suggest for the next pull request that would not only add sense pin, but a "fix" for controller turning off if turned on too early during system startup (a downside of the original puck too btw)

roman commented 2026-10-22 05:05:47 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Sep 30, 2026):

honestly, I can do an extra section in readme for the folks that are not as close to the beeps and boops as you are. I KINDA had to figure it out by myself even with that first setup w/o the sense pin, so might be useful for anyone that don't have that in them to learn too much new in order to make something work.

Just... for the love of God, check it afterwards for any grammatical non-sense.

<!-- gh-comment-id:5920680876 --> @Nikoroq commented on GitHub (Sep 30, 2026): honestly, I can do an extra section in readme for the folks that are not as close to the beeps and boops as you are. I KINDA had to figure it out by myself even with that first setup w/o the sense pin, so might be useful for anyone that don't have that in them to learn too much new in order to make something work. Just... for the love of God, check it afterwards for any grammatical non-sense.

roman commented 2026-10-22 05:05:48 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Oct 1, 2026):

yea please, and I'll approve before I merge it back to main, either post it here or or make a PR to my fork of the wiki page

<!-- gh-comment-id:5942210153 --> @katzmatt commented on GitHub (Oct 1, 2026): yea please, and I'll approve before I merge it back to main, either post it here or or make a PR to my fork of the wiki page

roman commented 2026-10-22 05:05:48 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Oct 2, 2026):

I assume the part about building the software with the right flags should not be included? It is about time to either include them by default or have a separate build each time there's a new release at main, separate version pre-built with the flags for the users that are up to lego their own cold-boot board.

it is one thing to build on Linux, a half an hour quest to set tools up, but it is a whole another movie episode in order to make it work on Windows.
I'd rather erase this part completely

<!-- gh-comment-id:5945741141 --> @Nikoroq commented on GitHub (Oct 2, 2026): I assume the part about building the software with the right flags should not be included? It is about time to either include them by default or have a separate build each time there's a new release at main, separate version pre-built with the flags for the users that are up to lego their own cold-boot board. it is one thing to build on Linux, a half an hour quest to set tools up, but it is a whole another movie episode in order to make it work on Windows. I'd rather erase this part completely

roman commented 2026-10-22 05:05:49 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Oct 2, 2026):

Test update : it wasn't due to fast boot. My system just loads too long, 36-40 seconds. Tried to tweak ram features for no success, so any way to tweak timeout timer on openpuck would be nice

<!-- gh-comment-id:5946882526 --> @Nikoroq commented on GitHub (Oct 2, 2026): Test update : it wasn't due to fast boot. My system just loads too long, 36-40 seconds. Tried to tweak ram features for no success, so any way to tweak timeout timer on openpuck would be nice

roman commented 2026-10-22 05:05:51 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Oct 13, 2026):

@Nikoroq just checking in if you got around to changing the wiki language as you wanted to, Otherwise ill make some changes and make the PR to main

<!-- gh-comment-id:6154602813 --> @katzmatt commented on GitHub (Oct 13, 2026): @Nikoroq just checking in if you got around to changing the wiki language as you wanted to, Otherwise ill make some changes and make the PR to main

roman commented 2026-10-22 05:05:52 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Oct 13, 2026):

@sponge were you able to test out these changes?

<!-- gh-comment-id:6154611870 --> @katzmatt commented on GitHub (Oct 13, 2026): @sponge were you able to test out these changes?

roman commented 2026-10-22 05:05:53 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Oct 14, 2026):

30. @Nikoroq just checking in if you got around to changing the wiki language as you wanted to, Otherwise ill make some changes and make the PR to main

Yeah I been waiting for you to answer my question... If it would be in the main already, it wouldn't make sense to include "Build with flags" part

<!-- gh-comment-id:6158056170 --> @Nikoroq commented on GitHub (Oct 14, 2026): > 30\. [@Nikoroq](https://github.com/Nikoroq) just checking in if you got around to changing the wiki language as you wanted to, Otherwise ill make some changes and make the PR to main Yeah I been waiting for you to answer my question... If it would be in the main already, it wouldn't make sense to include "Build with flags" part

roman commented 2026-10-22 05:05:53 +00:00

Author

Owner

Copy link

@katzmatt commented on GitHub (Oct 19, 2026):

you mean just have the feature enabled always? or to you mean move the voltage variables to a file rather than it being a build flag?
either way seems like not a bad idea.
@safijari do you have any strong opinions on this feature being enabled by default ?

<!-- gh-comment-id:6278563659 --> @katzmatt commented on GitHub (Oct 19, 2026): you mean just have the feature enabled always? or to you mean move the voltage variables to a file rather than it being a build flag? either way seems like not a bad idea. @safijari do you have any strong opinions on this feature being enabled by default ?

roman commented 2026-10-22 05:05:54 +00:00

Author

Owner

Copy link

@Nikoroq commented on GitHub (Oct 19, 2026):

31. you mean just have the feature enabled always? or to you mean move the voltage variables to a file rather than it being a build flag?
either way seems like not a bad idea.
@safijari do you have any strong opinions on this feature being enabled by default ?

What I think would be best, compatibility-wise, is to release cold-boot version (flags enabled) as a separate file and marking it as so, each time there's a new version in Releases.

Some kind of way to fuse measured voltage values without building uf2 file from scratch would be the right call, yes. If .txt file, that can be uploaded to the board, along with uf2 file is a feasible solution - it would be great.

Second thought: the logic, that would check, at the uf2 upload, whether certain .txt file is present or not, might trigger cold-boot sequence. If .txt not present alongside - cold-boot feature is down. This way each release might contain only a single file, instead of two separate versions.

But for that, webUI manual update logic should be changed, or modified: it is not too user-friendly to ask to delete .txt file via file manager if it is not needed anymore for some reason, so some kind of button, or a checkmark, to "keep cold-boot-voltage.txt during the update" would be nice.

I will write the simplified readme of the coldboot part accordingly, to what @safijari and you, @katzmatt will agree on

<!-- gh-comment-id:6279079950 --> @Nikoroq commented on GitHub (Oct 19, 2026): > 31\. you mean just have the feature enabled always? or to you mean move the voltage variables to a file rather than it being a build flag? > either way seems like not a bad idea. > [@safijari](https://github.com/safijari) do you have any strong opinions on this feature being enabled by default ? What I think would be best, compatibility-wise, is to release cold-boot version (flags enabled) as a separate file and marking it as so, each time there's a new version in Releases. Some kind of way to fuse measured voltage values without building uf2 file from scratch would be the right call, yes. If .txt file, that can be uploaded to the board, along with uf2 file is a feasible solution - it would be great. Second thought: the logic, that would check, at the uf2 upload, whether certain .txt file is present or not, might trigger cold-boot sequence. If .txt not present alongside - cold-boot feature is down. This way each release might contain only a single file, instead of two separate versions. But for that, webUI manual update logic should be changed, or modified: it is not too user-friendly to ask to delete .txt file via file manager if it is not needed anymore for some reason, so some kind of button, or a checkmark, to "keep cold-boot-voltage.txt during the update" would be nice. I will write the simplified readme of the coldboot part accordingly, to what @safijari and you, @katzmatt will agree on

roman referenced this issue 2026-10-22 05:07:45 +00:00

[PR #128] [MERGED] Fix firmware patcher #215

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

copilot/add-power-off-controller-when-charging

fix-lizard-dropped-reports

copilot/304

copilot/291

low-signal-polling

copilot/292

switch2pro

fix-playstation-modes

firmware

pr-247-fixes

copilot/246-feature-update

picopuck

HID-and-Sinput

bmac

fix-haptic-pulse-0x81

switch-gyro-config

copilot/170-add-controller-mapping

reconnect-issue-regression-fix

copilot/update-cfg-tud-hid-to-6

mode-announce

fix-stuck-input-when-changing-modes

rumble-scale

fix-switch-rumble-decode

full-wipe-mode

copilot/add-disable-rumble-option

fix-lizard-mode-grip-issue

copilot/update-switch-pro-mode

copilot/mouse-smoothness-issue

copilot/fix-restoring-config-failure

copilot/handle-puck-reconnection

fix-firmware-patcher

ble-test

copilot/review-125

copilot/gate-firmware-update-tab

copilot/add-remap-pure-lizard-mode-shortcuts

copilot/flash-uf2-from-webusb

copilot/fix-mouse-smoothness-openpuck

disabling-haptics-in-emulated-modes

copilot/resetreas-hex-value

copilot/review-119

copilot/compile-uf2-files

copilot/114-fortnite-ds5-controller-issue

copilot/save-hex-files-as-artifacts

copilot/tag-version-091

fix-haptics-regression

july-1-beta-update-compat

copilot/compare-main-commit-bf4c099

fix/lizard-multi-controller

ps3

stability-fix-refactor

stability-fix

zephyr-migration

attempt-at-fixing-connects

copilot/add-ps3-mode-gyro-haptics

copilot/discussion-72-reasons-solutions

copilot/add-slider-for-controller-mode

controller-emu

fix/buzz-link-stability

modern-standby-wake-fix

copilot/attach-hid-mouse-for-switch-pro-mode

steam-battery-fix

separate-configs-haptics-toggle-etc

copilot/feature78-ab-swap-nintendo-switch

multiple-controllers

more-closely-match-real-puck-comms

update-sniffer

copilot/fix-ci-uf2-upload

easier-dfu

switch-2-mouse-mode

stuck-haptics-another-attempt

ps5-ps4-fixes

cull-comments

formatter

copilot/fix-controller-disconnection-issue

copilot/fix-steam-battery-display-issue

steam-y-shutdown-global

switch-pro-mode-real-console

copilot/43

rumble

ds4-5-fixes-qam-mappings

lizard-maps-qam-maps-gyro-fix

bugfixes-mid-june-2026

led-poweroff-battery

more-buzz-and-quit

updated-docs

copilot/20

copilot/17

rearchitecture

new-controllers

copilot/11

weird-haptics-fix

initial_commit

0.9.67

0.9.66

0.9.65

0.9.64

0.9.63

0.9.62

0.9.61

0.9.60

0.9.59

0.9.58

0.9.57

0.9.56

0.9.55

0.9.54

0.9.53

0.9.52

0.9.51

0.9.50

0.9.49

0.9.48

0.9.47

0.9.46

0.9.45

0.9.44

0.9.43

0.9.42

0.9.41

0.9.40

0.9.39

0.9.38

0.9.37

0.9.36

0.9.35

0.9.34

0.9.33

0.9.32

0.9.31

0.9.30

0.9.29

0.9.28

0.9.27

0.9.26

0.9.25

0.9.24

0.9.23

0.9.22

0.9.21

0.9.20

0.9.19

0.9.18

0.9.17

0.9.16

0.9.15

0.9.14

0.9.13

0.9.12

0.9.11

0.9.10

0.9.9

0.9.8

0.9.7

0.9.4

0.9.6

0.9.3

0.9.2

0.9.1

Labels

Clear labels   

pull-request

Mirrored from GitHub Pull Request

  

wontfix

No labels

pull-request

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

safijari/openpuck#128

No description provided.