Switch OLED (Kamikaze) - Picofly Reset Error despite successful OFW boot and sound

  • Thread starter Thread starter abszs
  • Start date Start date
  • Views Views 325
  • Replies Replies 2

abszs

Member
Newcomer
Joined
May 12, 2009
Messages
11
Reaction score
1
Trophies
1
XP
215
Country
United States
I am currently troubleshooting a Switch OLED with a Kamikaze Picofly install that has a confusing modchip error. When I originally performed the mod, the chip glitched perfectly, but I noticed interference patterns on the screen. I incorrectly diagnosed this as a faulty FPC connector or a damaged S2DOS04 (Display PMIC) and proceeded to replace the connector and remove the IC. I eventually realized the interference was actually just caused by the USB-C shield not being attached to the board during testing.

After discovering the shielding was the issue, I resoldered the S2DOS04 back in place, but I accidentally caused some visible physical damage (pitting and charring) to the inductors surrounding the chip during the process. On the first boot after refitting the chip, the console successfully glitched and reached the "No SD Card" screen. However, since that first start, the Picofly has been stuck giving a ** (short-short) error code.

I have already swapped the Picofly for a fresh chip, but I am still getting the same reset point error. I measured the diode value on the reset line and am getting approximately 0.39V (red probe on ground), which appears to be healthy. The S2DOS04 is currently removed from the board, so I have no picture, but the console is successfully booting into the original firmware (OFW) in the background, confirmed by the fact that I have full sound and touch screen "clicks."

I am trying to determine why the Picofly is reporting a Reset error and failing to glitch when the console is clearly capable of booting into OFW with sound. It was able to glitch perfectly before the S2DOS04 was refitted and the inductors were damaged. I’m wondering if the heat-damaged inductors are creating enough electrical noise on the 1.8V logic rail to confuse the modchip’s timing, even though the rail is stable enough for the stock system to initialize?
WhatsApp Image 2026-05-31 at 00.31.38 (1).jpeg
 

Attachments

  • WhatsApp Image 2026-05-31 at 00.31.38.jpeg
    WhatsApp Image 2026-05-31 at 00.31.38.jpeg
    528.4 KB · Views: 8
I would not focus on the S2DOS04/display circuit first. If the console boots OFW in the background with sound and touch input, then the SoC is coming out of reset and the main boot sequence is alive. The missing picture is expected with S2DOS04 removed.

A Picofly `**` / short-short error still points to the reset line from the chip’s point of view. Since you already swapped the chip and got the same result, I’d suspect the install/wiring/pad condition more than the RP2040 itself.

Things I would check first:

* Recheck the RST wire from the chip to the reset point under a microscope.
* Check continuity from the chip pad all the way to the actual point, not just wire-end to wire-end.
* Check that RST is not partially bridged, cracked, lifted, or only making contact when pressed.
* Keep the RST wire as short as possible and away from noisy power/inductor areas.
* Reflow or redo the RST joint completely.
* Check chip ground quality. A weak ground can make a good reset reading behave badly in real use.
* Confirm 3.3V to the chip is stable during boot, not just present at rest.
* Try flashing known-good Picofly firmware again, just to eliminate firmware/config weirdness.

The damaged inductors near S2DOS04 could cause display/power-rail issues, but I’d expect that to show up as no image, unstable display power, or a console that fails normal boot. Since OFW still boots, I don’t think they are the main reason for a reset-specific Picofly error unless the RST wire is routed right through that noisy/damaged area or the damage also affected nearby traces/components.

Also, the 0.39V diode reading sounds reasonable, but it doesn’t prove the line behaves correctly dynamically. A cracked via/pad or poor solder joint can still pass diode/continuity checks and fail when the chip tries to pulse/reset during glitch timing.

My order would be:

1. Remove and redo RST.
2. Verify the reset point/pad condition under magnification.
3. Shorten/reroute RST away from the display PMIC/inductor area.
4. Verify chip GND and 3.3V under load.
5. Only then start chasing the damaged display-side inductors.

In other words: yes, electrical noise is possible in theory, but with a `**` code and two different chips showing the same thing, I’d treat this as a reset wiring / pad / grounding issue until proven otherwise.
 
I would not focus on the S2DOS04/display circuit first. If the console boots OFW in the background with sound and touch input, then the SoC is coming out of reset and the main boot sequence is alive. The missing picture is expected with S2DOS04 removed.

A Picofly `**` / short-short error still points to the reset line from the chip’s point of view. Since you already swapped the chip and got the same result, I’d suspect the install/wiring/pad condition more than the RP2040 itself.

Things I would check first:

* Recheck the RST wire from the chip to the reset point under a microscope.
* Check continuity from the chip pad all the way to the actual point, not just wire-end to wire-end.
* Check that RST is not partially bridged, cracked, lifted, or only making contact when pressed.
* Keep the RST wire as short as possible and away from noisy power/inductor areas.
* Reflow or redo the RST joint completely.
* Check chip ground quality. A weak ground can make a good reset reading behave badly in real use.
* Confirm 3.3V to the chip is stable during boot, not just present at rest.
* Try flashing known-good Picofly firmware again, just to eliminate firmware/config weirdness.

The damaged inductors near S2DOS04 could cause display/power-rail issues, but I’d expect that to show up as no image, unstable display power, or a console that fails normal boot. Since OFW still boots, I don’t think they are the main reason for a reset-specific Picofly error unless the RST wire is routed right through that noisy/damaged area or the damage also affected nearby traces/components.

Also, the 0.39V diode reading sounds reasonable, but it doesn’t prove the line behaves correctly dynamically. A cracked via/pad or poor solder joint can still pass diode/continuity checks and fail when the chip tries to pulse/reset during glitch timing.

My order would be:

1. Remove and redo RST.
2. Verify the reset point/pad condition under magnification.
3. Shorten/reroute RST away from the display PMIC/inductor area.
4. Verify chip GND and 3.3V under load.
5. Only then start chasing the damaged display-side inductors.

In other words: yes, electrical noise is possible in theory, but with a `**` code and two different chips showing the same thing, I’d treat this as a reset wiring / pad / grounding issue until proven otherwise.
Normally I solder the reset point wire at the back of the board, I have since moved it to the front but I'm still having the same issue. I should also add I get the same diode values at the back and front of the board. Regarding your fourth point, I measured the 3v3 rail under load and I was getting 3.3v when the board was powered on. I'm getting about 0v on the ground point of the chip when powered on.
WhatsApp Image 2026-06-01 at 09.48.54 (1).jpeg
WhatsApp Image 2026-06-01 at 09.48.54.jpeg

Post automatically merged:

I should also add that I did end up removing the inducers but still have the same problem
Post automatically merged:

Another small update, I measured the reset point live voltage and I'm getting around 1.18v when compared to 1.78 on another healthy board. I'm not sure what could be causing this drop in voltage?
 
Last edited by abszs,

Site & Scene News

Popular threads in this forum