Picofly AIO Thread

[gamerfuel]

Hi, I installed a Picofly in an unpatched Erista Switch, and it works fine if I power the Switch on while it isn't plugged into anything. However, if it's connected to a charger, the Switch boots into RCM mode and stays there. There are no lights from the Picofly at all when this happens. After unplugging and forcing a power cycle, the Switch boots properly again. Is this normal?

 

[Nephiel]

installed a Picofly in an unpatched Erista

OK, first of all, why? As those can be softmodded...

However, if it's connected to a charger, the Switch boots into RCM mode and stays there.

Maybe AutoRCM is enabled, I would check that next.

 

[hippy dave]

Hi, I installed a Picofly in an unpatched Erista Switch, and it works fine if I power the Switch on while it isn't plugged into anything. However, if it's connected to a charger, the Switch boots into RCM mode and stays there. There are no lights from the Picofly at all when this happens. After unplugging and forcing a power cycle, the Switch boots properly again. Is this normal?

Weird question especially as you installed it yourself, but are you sure it's a picofly glitch chip? The behaviour sounds like what happens with a trinket-type payload-pushing chip, which puts the Switch in RCM, but if there's a USB cable plugged in then it can't push the payload.
If it is one of the latter kind, then you can either flash it with a firmware that will reset the chip and push again when the cable is disconnected, or if it has a button then you can usually press the back case in the right place to reset the chip and push again.

 

[gamerfuel]

OK, first of all, why? As those can be softmodded...


Maybe AutoRCM is enabled, I would check that next.

I wanted to be able to boot from a powered-off state without a computer or jig.
According to Hekate, AutoRCM is off. I can't even enable AutoRCM via Hekate - attempting to toggle just says that it is still off.

Weird question especially as you installed it yourself, but are you sure it's a picofly glitch chip? The behaviour sounds like what happens with a trinket-type payload-pushing chip, which puts the Switch in RCM, but if there's a USB cable plugged in then it can't push the payload.
If it is one of the latter kind, then you can either flash it with a firmware that will reset the chip and push again when the cable is disconnected, or if it has a button then you can usually press the back case in the right place to reset the chip and push again.

Yep, it's a picofly - picofly toolbox reports it as using fw 2.73.

 

[hippy dave]

I wanted to be able to boot from a powered-off state without a computer or jig.
According to Hekate, AutoRCM is off. I can't even enable AutoRCM via Hekate - attempting to toggle just says that it is still off.


Yep, it's a picofly - picofly toolbox reports it as using fw 2.73.

Weird. I'm no expert on the glitch chips but I don't think entering RCM is intended to be part of the process. It's what would happen if the EMMC couldn't be accessed, but I'm not sure how that could be dependent on something being plugged into USB or not.

 

[gamerfuel]

Thanks guys; it ended up being a completely separate issue. I'll document what I did below in case someone has a similar problem in the future.

I thought maybe Hekate refusing to toggle AutoRCM could be related to the problem, and I guessed Picofly was preventing AutoRCM from being toggled. After removing the Picofly, I was able to toggle AutoRCM, and I reinstalled the Picofly. This ultimately didn't do anything useful: instead of starting in RCM mode when plugging in a cable while powered off, it started the official bootloader. I turned AutoRCM back on, and I was back to where I started. So failing to toggle AutoRCM is a red herring.

(An aside: Hekate 6.1.1 incorrectly reported AutoRCM as being off, and I couldn't toggle from the off state. However, with Hekate 5.0.0, it correctly reported AutoRCM as being on, being unable to toggle from the on state. So you might not be able to trust what Hekate reports for AutoRCM when you have a Picofly installed.)

After that, I started checking for continuity between the eMMC connector and various parts of the board, using the Picofly install guide as a reference. I'm using a Picofly kit from Aliexpress, which contains a board that plugs into the eMMC connector and a flex cable to solder to the APU capacitors, so I didn't need to solder to the board besides at the APU capacitors. I was just checking for any signs of board / trace damage out of desperation.

I ended up finding what I believe to be two missing capacitors on my Erista board: the 3.3V point in the attached image, along with the capacitor north of it. (Image taken from the Picofly Install Guide). Not only were the capacitors missing, but the north pad of the 3.3V capacitor was bridged with both pads of the capacitor above it under a glob of solder. I got my Switch used years ago, and I've never had a problem with it prior to the Picofly install, but I guess a previous owner tried to mod it and got sloppy.

I wicked away excess solder and reflowed the pads to remove all the bridges, so that none of the pads are connected to each other. And now my problem is fixed: Picofly starts up when plugging in a charger or USB cable when the Switch is powered off. I'm a little concerned that I've being using my Switch without these capacitors for so long, but I haven't had issues in years of use, so I don't know if they're worth the risk of replacing.

My situation is pretty unique, but if someone's installing a Picofly by soldering directly to the board and runs into the same problem as me, double check that there are no bridges between any of the components around that 3.3V capacitor, either from solder or flux / IPA, because it appears that can prevent the Picofly from starting up when the Switch gets plugged in while powered off.

 

[Karichi1919]

I'm getting an endless pulsating blue light, eventually it stops working. Could it be bad emmc? I can't boot on stock either, wanted to use the chip to diagnose.

 

[abal1000x]

I'm getting an endless pulsating blue light, eventually it stops working. Could it be bad emmc? I can't boot on stock either, wanted to use the chip to diagnose.

Try to update to last firmware version for better diagnose.
https://github.com/rehius/usk/releases

 

[Karichi1919]

Try to update to last firmware version for better diagnose.
https://github.com/rehius/usk/releases

Can't tell if I'm getting === or ***. Considering how long it's taking, it's probably ===

 

[abal1000x]

Can't tell if I'm getting === or ***. Considering how long it's taking, it's probably ===

The main suspect is the mosfet, try to change it.

Second is the emmc line cmd/dat0/clk.
Make sure the solder are good enough.

 

[LuigiGad]

Can't tell if I'm getting === or ***. Considering how long it's taking, it's probably ===

Once on a Mariko I forgot to hook up the eMMC before starting it and I had === on Picofly

 

[k28]

what resistor you have on dat0

47 ohm

 

[Karichi1919]

Once on a Mariko I forgot to hook up the eMMC before starting it and I had === on Picofly

This sounds like it might be my case, fried emmc acting like it just ain't there.

 

[jkyoho]

47 ohm

increase resistance to 100 ohm or more and check again

 

[abal1000x]

This sounds like it might be my case, fried emmc acting like it just ain't there.

If the emmc is totally dead, you'll get different error.

There will be no white led, in the first time you turn on the picofly.
Those white led means picofly writing to the emmc.
If its failed, it will throws error.

Theres also bunch of emmc check before the glitch.
You will stuck with those errors.

Thats error (===) happened after all check on the emmc are ok.
If its indeed the emmc then the probable scenario is partial broken emmc.

The most logical one is the mosfet, and unstable connection to the emmc line (cmd/dat0/clk)

Picofly will try to glitch from a range of offset, randomly pick one by one until exhaust before throwing ===.
And everytime its glitch, it will read the response of the emmc (sniff) on cmd line.
If the response 'normal' it will repeat the glitch on another offset, until exhausted.

 

[Karichi1919]

If the emmc is totally dead, you'll get different error.

There will be no white led, in the first time you turn on the picofly.
Those white led means picofly writing to the emmc.
If its failed, it will throws error.

Theres also bunch of emmc check before the glitch.
You will stuck with those errors.

Thats error (===) happened after all check on the emmc are ok.
If its indeed the emmc then the probable scenario is partial broken emmc.

The most logical one is the mosfet, and unstable connection to the emmc line (cmd/dat0/clk)

Picofly will try to glitch from a range of offset, randomly pick one by one until exhaust before throwing ===.
And everytime its glitch, it will read the response of the emmc (sniff) on cmd line.
If the response 'normal' it will repeat the glitch on another offset, until exhausted.

I swapped the emmc, it works now. I had full backups of the old original emmc, that is RAW GPP and BOOT0/1, as well as prod keys. I'm hoping just restoring them will work and won't get me banned. I never dumped the bis keys so I hope I didn't need them

Post automatically merged: Apr 15, 2024

I swapped the emmc, it works now. I had full backups of the old original emmc, that is RAW GPP and BOOT0/1, as well as prod keys. I'm hoping just restoring them will work and won't get me banned. I never dumped the bis keys so I hope I didn't need them

Initialized in slow mode, I guess I need to try yet another emmc. I've already increased the resistors to 100 ohm

Post automatically merged: Apr 15, 2024

Aaand it booted once or twice but then I get 2002-3539

 

[Warbeast81]

Thanks guys; it ended up being a completely separate issue. I'll document what I did below in case someone has a similar problem in the future.

I thought maybe Hekate refusing to toggle AutoRCM could be related to the problem, and I guessed Picofly was preventing AutoRCM from being toggled. After removing the Picofly, I was able to toggle AutoRCM, and I reinstalled the Picofly. This ultimately didn't do anything useful: instead of starting in RCM mode when plugging in a cable while powered off, it started the official bootloader. I turned AutoRCM back on, and I was back to where I started. So failing to toggle AutoRCM is a red herring.

(An aside: Hekate 6.1.1 incorrectly reported AutoRCM as being off, and I couldn't toggle from the off state. However, with Hekate 5.0.0, it correctly reported AutoRCM as being on, being unable to toggle from the on state. So you might not be able to trust what Hekate reports for AutoRCM when you have a Picofly installed.)

After that, I started checking for continuity between the eMMC connector and various parts of the board, using the Picofly install guide as a reference. I'm using a Picofly kit from Aliexpress, which contains a board that plugs into the eMMC connector and a flex cable to solder to the APU capacitors, so I didn't need to solder to the board besides at the APU capacitors. I was just checking for any signs of board / trace damage out of desperation.

I ended up finding what I believe to be two missing capacitors on my Erista board: the 3.3V point in the attached image, along with the capacitor north of it. (Image taken from the Picofly Install Guide). Not only were the capacitors missing, but the north pad of the 3.3V capacitor was bridged with both pads of the capacitor above it under a glob of solder. I got my Switch used years ago, and I've never had a problem with it prior to the Picofly install, but I guess a previous owner tried to mod it and got sloppy.

I wicked away excess solder and reflowed the pads to remove all the bridges, so that none of the pads are connected to each other. And now my problem is fixed: Picofly starts up when plugging in a charger or USB cable when the Switch is powered off. I'm a little concerned that I've being using my Switch without these capacitors for so long, but I haven't had issues in years of use, so I don't know if they're worth the risk of replacing.

My situation is pretty unique, but if someone's installing a Picofly by soldering directly to the board and runs into the same problem as me, double check that there are no bridges between any of the components around that 3.3V capacitor, either from solder or flux / IPA, because it appears that can prevent the Picofly from starting up when the Switch gets plugged in while powered off.

I had a similar one I think the caps are for vsvr and vccin. the console turned on fine using the power button and would charge once on but wouldn't auto switch on using a charging cable so once the battery was dead it wouldn't detect the cable to charge again. I replaced the caps with 1uf or 2.2 plus the m92 and all was good

 

[k28]

increase resistance to 100 ohm or more and check again

thx for the reply. i increased to 147ohm. still the same problem. Should i increase more? what else could i try?

 

[PikachuPrincess23]

I need help regarding my Nintendo Switch lite with Picofly.

1. I can't connect to online and get this error.

2. I can't transfer file over USB, I get this error" BuffData: 189: USB transfer timed out or failed" on Awoo Installer and I get same error on DBI.
Please help me.

 

[jkyoho]

I need help regarding my Nintendo Switch lite with Picofly.

1. I can't connect to online and get this error.

2. I can't transfer file over USB, I get this error" BuffData: 189: USB transfer timed out or failed" on Awoo Installer and I get same error on DBI.
Please help me.

https://gbatemp.net/threads/error-2123-0011-0x167b.643562/post-10298160
Do not use exosphere.ini blank prodinfo from FW17.0+, use DNSmitm and 90dns block together instead