Hacking Hardware Picofly - a HWFLY switch modchip

remlei

Well-Known Member
Member
Joined
Mar 26, 2013
Messages
191
Trophies
2
Age
35
XP
690
Country
Hi,

I am very lost, it's the first time I see this issue. On switch lite, i have 1 of 10 times the *== (short long long) error....
I am used to this on OLEDS ==> i fix this by switching to an instinct-nx...

On the lite i've tried two rp2040, and now with a tiny the problem is still there.

Here are my readings and some pictures of the installation.

3v3 : 7,75
d0 (c) : 5.25
cmd (a) : 6,62
clk (d) : 6,68
rst (b) : 12,14
cpu : 5.59

I replied to you previously. It is the dat0 connection. Even if the value is correct please just redo it. I had the exact same problem previously.

well I read that yours is fixed by redoing the dat0 connection right? though unfortunately for me, this has been done on my OLED multiple times, not only DAT0 but every single wire connection. same issue, alas only instinct-nx is the reliable one.

im using that EMMC adapter that basically requires reballing both the adapter and the EMMC sandwich together which in turn exposed multiple points (not only dat0) so scarping the part near the CPU is no longer required.
 

lightautodark

Well-Known Member
Member
Joined
Jul 12, 2024
Messages
109
Trophies
0
Age
33
XP
194
Country
United Kingdom
well I read that yours is fixed by redoing the dat0 connection right? though unfortunately for me, this has been done on my OLED multiple times, not only DAT0 but every single wire connection. same issue, alas only instinct-nx is the reliable one.

im using that EMMC adapter that basically requires reballing both the adapter and the EMMC sandwich together which in turn exposed multiple points (not only dat0) so scarping the part near the CPU is no longer required.
You can do whatever you think is best to solve your problem. Your problem, your solution, no one can tell you otherwise.
 

retnuh730

Well-Known Member
Member
Joined
May 17, 2023
Messages
113
Trophies
0
Age
34
XP
322
Country
United States
Hey all, is there an explanation on a hardware level of how the chip is able to get a payload to boot? I tried searching but wasn’t successful. I just like learning about this stuff!
 
  • Like
Reactions: Tom8823

thepussyvanished

Member
Newcomer
Joined
May 5, 2024
Messages
12
Trophies
0
Age
23
XP
18
Country
United States
How do I start over? It already has a modchip, I just wanna re-install the mods because Mariko refuses to boot, the logo loads then fades into black.
They say to delete everything except the Nintendo Folder, but I don't even see the Nintendo folder on mine. And since the Rentry Guide got taken down, I don't know what to do.
 

thesjaakspoiler

Well-Known Member
Member
Joined
Nov 20, 2018
Messages
1,320
Trophies
0
Age
124
XP
1,944
Country
Afghanistan
Hey all, is there an explanation on a hardware level of how the chip is able to get a payload to boot? I tried searching but wasn’t successful. I just like learning about this stuff!
It's a freakish complex hack, combining a series of hacks.
But this is how it works as far as I know :
(anyone feel free to correct me if I'm wrong)

The modchip is not a single hack but consists of 3 hacks :
The first hacking method is 'custom data injection'.
The second hacking method is called 'voltage glitching'.
The third hack is circumventing the security measures that normally prevent the execution of unsigned code and providing the homebrew menu.

Before the SX Core/HWFly/Picofly, only the first generation of Switches could be hacked.
For the first Switches (V1 unpatched), the debug mode of the Tegra could be used to load a custom bootloader.
All before the secure environment was started so one would be in full control of the Switch, right from the start.
This is used to hack the OS so that it can execute unsigned code and add the homebrew menu to the Album button (and later many more things).
When the operating system is running with this hack, it does no longer check certificates of the software and can thus run anything.
That was really like leaving the backdoor wide open.
This was a real blunder of epic proportions, not only because of this debug mode left enabled on production devices.
The code enabling resides in ROM inside the CPU so it cannot be patched/fixed.
For the newer generation Switches, this debug mode was disabled so there was no longer a way to start custom code anymore.
The rest of Nintendo's security model was perfect and up until this day no software hack has been found.

Until someone combined voltage glitching with data injection to get control over the boot proces like with the V1 debug mode.

The boot process starts with some code in ROM inside the CPU.
That checks if the bootloader in the emmc is signed with the right encryption key.
If that check fails, the cpu just stops the boot process. Game over.
Since we don't know the encryption key to sign the bootloader, we cannot replace the bootloader in the emmc with our own code.
That would be pretty trivial to do as the emmc has no security whatsoever.

When the custom data injection hack and voltage hack are combined, it allows us to execute a custom boot loader as before.
The modchip replaces data from the emmc with a custom bootloader with a data injection hack.
The cpu thinks it is reading from the emmc but the modchip is providing a custom bootloader.
Normally the cpu would reject this custom bootloader.
This is where the voltage glitch hack comes into play.
A voltage glitch lowers the voltage to the cpu for just a brief moment by shorting the + and - voltage lines with a mosfet.
(That is why the ribbon cable needed to be soldered to the top of the cpu at first. Later someone found a way to do it on the backside.)
This causes the cpu to just completely ignore a command and continue with the next command.
In case of the Switch, the voltage glitch is executed when the CPU needs to make a decision whether the bootloader it loaded is valid or not.
Normally it would go to the section where it terminates the execution of the bootloader.
With the voltage hack, the cpu skips the encryption check and continues as if our custom bootloader was signed with a valid encryption key.
So the custom bootloader is started and this opens the gates to the castle with the third hack.
The moment when to lower the voltage is very critical and this is what the training of the modchip is doing.
Depending on the model of the Switch and the type of emmc used, the timings differ so the timing must be determined for each individual Switch.
The modchip has a way to see if the voltage glitch succeeded or not.
Once it determines the right moment to glitch, it stores this timing and then it just takes an instant to boot the next time.

The modchip is connected to the emmc to disable it so the modchip can inject its own bootloader.
Normally the emmc has 8 datalines but it has a special mode so that it can run in 1 bit mode.
The modchip uses this feature as well so that only 1 wire is needed as a dataline.
That saves soldering 7 other wires.
Finally the reset line is used by the modchip for timing the glitch and to reset the cpu during training mode.

Team Xecuter was the first to come up with a modchip but they just read the detailed paper/blog from Yifan Lu.
She hacked the PSVita in 2018 and Team Xecuter announced their modchip just a few months afterwards :
http://arxiv.org/pdf/1903.08102
Team Xecuter used a low cost cpu with an FPGA to determine the timing of the glitch, glitching the Switch and to do the data injection.
FPGA are (re)programmable custom chips that can easily keep up with fast signals and timings.
Implementing everything inside an FPGA would technically be possible but not very flexible.
To provide flexibility to the modchip, Team Xecuter choose this low cost cpu + fpga set up.
This allowed to store the custom bootloader in the cpu and connect to it over USB.

But Bowser was caught by Nintendo Ninjas and the whole Team Xecuter operation was shut down.
But the designs and code somehow leaked from the Chinese manufacturers of the SX Core and started a second life with the HWFly.
In 2022, someone came up with the idea to use a Raspberry Pi.
A Raspberry Pi is much faster so no FPGA would be needed.
And the RP2040 (Raspberry Pi Pico) is really small so it would fit inside the Switch.
This is what became known as the PicoFly.

The original SX Core source code is here but I recall the FPGA source code was available at the time.
That was just a binary blob.
But you can learn a lot from this.
https://github.com/Spacecraft-NX/firmware

The Picofly code is also available :
https://github.com/Ansem-SoD/Picofly

Before you go out to hack your PS5 with voltage glitching,
some modern CPUs have protective measures against such attacks and even by reordering the code, it is possible to prevent such a hack.
So not everything can be hacked this way.

It's going to be fun to see what the Switch2 will have in store.
I guess Nintendo learned a lesson or 2 with the Switch 1.
 

retnuh730

Well-Known Member
Member
Joined
May 17, 2023
Messages
113
Trophies
0
Age
34
XP
322
Country
United States
It's a freakish complex hack, combining a series of hacks.
But this is how it works as far as I know :
(anyone feel free to correct me if I'm wrong)

The modchip is not a single hack but consists of 3 hacks :
The first hacking method is 'custom data injection'.
The second hacking method is called 'voltage glitching'.
The third hack is circumventing the security measures that normally prevent the execution of unsigned code and providing the homebrew menu.

Before the SX Core/HWFly/Picofly, only the first generation of Switches could be hacked.
For the first Switches (V1 unpatched), the debug mode of the Tegra could be used to load a custom bootloader.
All before the secure environment was started so one would be in full control of the Switch, right from the start.
This is used to hack the OS so that it can execute unsigned code and add the homebrew menu to the Album button (and later many more things).
When the operating system is running with this hack, it does no longer check certificates of the software and can thus run anything.
That was really like leaving the backdoor wide open.
This was a real blunder of epic proportions, not only because of this debug mode left enabled on production devices.
The code enabling resides in ROM inside the CPU so it cannot be patched/fixed.
For the newer generation Switches, this debug mode was disabled so there was no longer a way to start custom code anymore.
The rest of Nintendo's security model was perfect and up until this day no software hack has been found.

Until someone combined voltage glitching with data injection to get control over the boot proces like with the V1 debug mode.

The boot process starts with some code in ROM inside the CPU.
That checks if the bootloader in the emmc is signed with the right encryption key.
If that check fails, the cpu just stops the boot process. Game over.
Since we don't know the encryption key to sign the bootloader, we cannot replace the bootloader in the emmc with our own code.
That would be pretty trivial to do as the emmc has no security whatsoever.

When the custom data injection hack and voltage hack are combined, it allows us to execute a custom boot loader as before.
The modchip replaces data from the emmc with a custom bootloader with a data injection hack.
The cpu thinks it is reading from the emmc but the modchip is providing a custom bootloader.
Normally the cpu would reject this custom bootloader.
This is where the voltage glitch hack comes into play.
A voltage glitch lowers the voltage to the cpu for just a brief moment by shorting the + and - voltage lines with a mosfet.
(That is why the ribbon cable needed to be soldered to the top of the cpu at first. Later someone found a way to do it on the backside.)
This causes the cpu to just completely ignore a command and continue with the next command.
In case of the Switch, the voltage glitch is executed when the CPU needs to make a decision whether the bootloader it loaded is valid or not.
Normally it would go to the section where it terminates the execution of the bootloader.
With the voltage hack, the cpu skips the encryption check and continues as if our custom bootloader was signed with a valid encryption key.
So the custom bootloader is started and this opens the gates to the castle with the third hack.
The moment when to lower the voltage is very critical and this is what the training of the modchip is doing.
Depending on the model of the Switch and the type of emmc used, the timings differ so the timing must be determined for each individual Switch.
The modchip has a way to see if the voltage glitch succeeded or not.
Once it determines the right moment to glitch, it stores this timing and then it just takes an instant to boot the next time.

The modchip is connected to the emmc to disable it so the modchip can inject its own bootloader.
Normally the emmc has 8 datalines but it has a special mode so that it can run in 1 bit mode.
The modchip uses this feature as well so that only 1 wire is needed as a dataline.
That saves soldering 7 other wires.
Finally the reset line is used by the modchip for timing the glitch and to reset the cpu during training mode.

Team Xecuter was the first to come up with a modchip but they just read the detailed paper/blog from Yifan Lu.
She hacked the PSVita in 2018 and Team Xecuter announced their modchip just a few months afterwards :
http://arxiv.org/pdf/1903.08102
Team Xecuter used a low cost cpu with an FPGA to determine the timing of the glitch, glitching the Switch and to do the data injection.
FPGA are (re)programmable custom chips that can easily keep up with fast signals and timings.
Implementing everything inside an FPGA would technically be possible but not very flexible.
To provide flexibility to the modchip, Team Xecuter choose this low cost cpu + fpga set up.
This allowed to store the custom bootloader in the cpu and connect to it over USB.

But Bowser was caught by Nintendo Ninjas and the whole Team Xecuter operation was shut down.
But the designs and code somehow leaked from the Chinese manufacturers of the SX Core and started a second life with the HWFly.
In 2022, someone came up with the idea to use a Raspberry Pi.
A Raspberry Pi is much faster so no FPGA would be needed.
And the RP2040 (Raspberry Pi Pico) is really small so it would fit inside the Switch.
This is what became known as the PicoFly.

The original SX Core source code is here but I recall the FPGA source code was available at the time.
That was just a binary blob.
But you can learn a lot from this.
https://github.com/Spacecraft-NX/firmware

The Picofly code is also available :
https://github.com/Ansem-SoD/Picofly

Before you go out to hack your PS5 with voltage glitching,
some modern CPUs have protective measures against such attacks and even by reordering the code, it is possible to prevent such a hack.
So not everything can be hacked this way.

It's going to be fun to see what the Switch2 will have in store.
I guess Nintendo learned a lesson or 2 with the Switch 1.
This is exactly what i was wanting to learn. This very cool. Thank you so much for sharing!!
 

lightautodark

Well-Known Member
Member
Joined
Jul 12, 2024
Messages
109
Trophies
0
Age
33
XP
194
Country
United Kingdom

thepussyvanished

Member
Newcomer
Joined
May 5, 2024
Messages
12
Trophies
0
Age
23
XP
18
Country
United States
Thank you! But how do I start over? This is what I see when I insert the SD card.
Screenshot 2024-10-09 122431.png
 

deeps

Well-Known Member
Member
Joined
Jul 3, 2007
Messages
495
Trophies
1
XP
1,470
Country
It's a freakish complex hack, combining a series of hacks.
But this is how it works as far as I know :
(anyone feel free to correct me if I'm wrong)

The modchip is not a single hack but consists of 3 hacks :
The first hacking method is 'custom data injection'.
The second hacking method is called 'voltage glitching'.
The third hack is circumventing the security measures that normally prevent the execution of unsigned code and providing the homebrew menu.

Before the SX Core/HWFly/Picofly, only the first generation of Switches could be hacked.
For the first Switches (V1 unpatched), the debug mode of the Tegra could be used to load a custom bootloader.
All before the secure environment was started so one would be in full control of the Switch, right from the start.
This is used to hack the OS so that it can execute unsigned code and add the homebrew menu to the Album button (and later many more things).
When the operating system is running with this hack, it does no longer check certificates of the software and can thus run anything.
That was really like leaving the backdoor wide open.
This was a real blunder of epic proportions, not only because of this debug mode left enabled on production devices.
The code enabling resides in ROM inside the CPU so it cannot be patched/fixed.
For the newer generation Switches, this debug mode was disabled so there was no longer a way to start custom code anymore.
The rest of Nintendo's security model was perfect and up until this day no software hack has been found.

Until someone combined voltage glitching with data injection to get control over the boot proces like with the V1 debug mode.

The boot process starts with some code in ROM inside the CPU.
That checks if the bootloader in the emmc is signed with the right encryption key.
If that check fails, the cpu just stops the boot process. Game over.
Since we don't know the encryption key to sign the bootloader, we cannot replace the bootloader in the emmc with our own code.
That would be pretty trivial to do as the emmc has no security whatsoever.

When the custom data injection hack and voltage hack are combined, it allows us to execute a custom boot loader as before.
The modchip replaces data from the emmc with a custom bootloader with a data injection hack.
The cpu thinks it is reading from the emmc but the modchip is providing a custom bootloader.
Normally the cpu would reject this custom bootloader.
This is where the voltage glitch hack comes into play.
A voltage glitch lowers the voltage to the cpu for just a brief moment by shorting the + and - voltage lines with a mosfet.
(That is why the ribbon cable needed to be soldered to the top of the cpu at first. Later someone found a way to do it on the backside.)
This causes the cpu to just completely ignore a command and continue with the next command.
In case of the Switch, the voltage glitch is executed when the CPU needs to make a decision whether the bootloader it loaded is valid or not.
Normally it would go to the section where it terminates the execution of the bootloader.
With the voltage hack, the cpu skips the encryption check and continues as if our custom bootloader was signed with a valid encryption key.
So the custom bootloader is started and this opens the gates to the castle with the third hack.
The moment when to lower the voltage is very critical and this is what the training of the modchip is doing.
Depending on the model of the Switch and the type of emmc used, the timings differ so the timing must be determined for each individual Switch.
The modchip has a way to see if the voltage glitch succeeded or not.
Once it determines the right moment to glitch, it stores this timing and then it just takes an instant to boot the next time.

The modchip is connected to the emmc to disable it so the modchip can inject its own bootloader.
Normally the emmc has 8 datalines but it has a special mode so that it can run in 1 bit mode.
The modchip uses this feature as well so that only 1 wire is needed as a dataline.
That saves soldering 7 other wires.
Finally the reset line is used by the modchip for timing the glitch and to reset the cpu during training mode.

Team Xecuter was the first to come up with a modchip but they just read the detailed paper/blog from Yifan Lu.
She hacked the PSVita in 2018 and Team Xecuter announced their modchip just a few months afterwards :
http://arxiv.org/pdf/1903.08102
Team Xecuter used a low cost cpu with an FPGA to determine the timing of the glitch, glitching the Switch and to do the data injection.
FPGA are (re)programmable custom chips that can easily keep up with fast signals and timings.
Implementing everything inside an FPGA would technically be possible but not very flexible.
To provide flexibility to the modchip, Team Xecuter choose this low cost cpu + fpga set up.
This allowed to store the custom bootloader in the cpu and connect to it over USB.

But Bowser was caught by Nintendo Ninjas and the whole Team Xecuter operation was shut down.
But the designs and code somehow leaked from the Chinese manufacturers of the SX Core and started a second life with the HWFly.
In 2022, someone came up with the idea to use a Raspberry Pi.
A Raspberry Pi is much faster so no FPGA would be needed.
And the RP2040 (Raspberry Pi Pico) is really small so it would fit inside the Switch.
This is what became known as the PicoFly.

The original SX Core source code is here but I recall the FPGA source code was available at the time.
That was just a binary blob.
But you can learn a lot from this.
https://github.com/Spacecraft-NX/firmware

The Picofly code is also available :
https://github.com/Ansem-SoD/Picofly

Before you go out to hack your PS5 with voltage glitching,
some modern CPUs have protective measures against such attacks and even by reordering the code, it is possible to prevent such a hack.
So not everything can be hacked this way.

It's going to be fun to see what the Switch2 will have in store.
I guess Nintendo learned a lesson or 2 with the Switch 1.

Slight correction - the modchip doesn't do any "injection hack", it simply overwrites the bootloader in the emmc while keeping the cpu in reset state (this is the initial long white light you see on first boot after installing the modchip). The reason the system can still boot normally without modchip is that there is a backup of boot0 at another address in the emmc that will be loaded if the signature check of the primary one fails

other than that everything you've said seems accurate to me
 

Tom8823

Well-Known Member
Newcomer
Joined
Jun 22, 2020
Messages
78
Trophies
0
Age
36
XP
696
Country
Canada
So what you are saying is that on Mariko 100/100/47 combination should work no matter what?
Because for me it works only once. I will try to investigate. Before installing new chip I will try to replace my wires because I used 30 AWG enamel on all points including 3V and ground.

Can I please have a list of diode readings on all points to measure? I will check my console.

Also should I measure those points with battery connected or disconnected?

Thanks to everyone involved for help.
I think my issue should be gone now. Since it wasn't easy to recreate it (because it was happening months or weeks apart) I decided to fix it until combination of 100/100/47 works. And I managed to do that.

I replaced ground and 3V wires for a little bit thicker wires. I left enameled wires only on data points but 3v and ground I used standard copper wire. Before console with 100 ohm resistor on cmd would start only once and wouldn't start anymore (also no led light on chip). Now after this work it starts each time with instant glitch.

I hope that means my console won't be having issues with booting after some time now.

It's me again, unfortunately my happiness didn't last long. Problem is back again, console suddenly wouldn't turn on after shut down. However this time I managed to make some measurements and I spotted something interesting.

While my console was "off" and I pressed power on button and nothing was happening (no LED light on chip as well) I took my multimeter and measured each point on chip for voltages. To my surprise 3v point was staying at 3.3V all the time, point DAT0 was staying at 1V and point RST was at 593mV.

That would explain why couple of days ago my console died even though I shut it down with 63% battery. Looks like sometimes even though I shut off my console some voltages don't go to 0.

Could that be faulty chip? Or something else like my mosfet? It's really bizarre that voltages stay active and prevent me from turning on my console unless I press long power button (which sometimes doesn't help and I have to open console to reconnect battery)

@rehius have you seen something like this? Could that be firmware error?
 

twins333

Well-Known Member
Member
Joined
May 30, 2023
Messages
102
Trophies
0
XP
452
Country
Afghanistan
It's me again, unfortunately my happiness didn't last long. Problem is back again, console suddenly wouldn't turn on after shut down. However this time I managed to make some measurements and I spotted something interesting.

While my console was "off" and I pressed power on button and nothing was happening (no LED light on chip as well) I took my multimeter and measured each point on chip for voltages. To my surprise 3v point was staying at 3.3V all the time, point DAT0 was staying at 1V and point RST was at 593mV.

That would explain why couple of days ago my console died even though I shut it down with 63% battery. Looks like sometimes even though I shut off my console some voltages don't go to 0.

Could that be faulty chip? Or something else like my mosfet? It's really bizarre that voltages stay active and prevent me from turning on my console unless I press long power button (which sometimes doesn't help and I have to open console to reconnect battery)

@rehius have you seen something like this? Could that be firmware error?
I think it's not a firmware issue, because it should happen to a lot more people. Did you try a new chip?
 
  • Like
Reactions: Tom8823

abal1000x

Well-Known Member
Member
Joined
Jun 5, 2022
Messages
1,132
Trophies
0
XP
1,629
Country
Gaza Strip
It's me again, unfortunately my happiness didn't last long. Problem is back again, console suddenly wouldn't turn on after shut down. However this time I managed to make some measurements and I spotted something interesting.

While my console was "off" and I pressed power on button and nothing was happening (no LED light on chip as well) I took my multimeter and measured each point on chip for voltages. To my surprise 3v point was staying at 3.3V all the time, point DAT0 was staying at 1V and point RST was at 593mV.

That would explain why couple of days ago my console died even though I shut it down with 63% battery. Looks like sometimes even though I shut off my console some voltages don't go to 0.

Could that be faulty chip? Or something else like my mosfet? It's really bizarre that voltages stay active and prevent me from turning on my console unless I press long power button (which sometimes doesn't help and I have to open console to reconnect battery)

@rehius have you seen something like this? Could that be firmware error?
Its doesn't relate to the picofly.
It means the 3.3V doesn't turn off.
Picofly took the 3.3V from the pm ic.

The first thing you need to check, from what point is the picofly took the 3.3V. It might use the wrong point, but its less probable, since there are already guide in everywhere.

The second thing is check the pm ic, it could be partial broken. Theres no other way then replace the pm ic.
 
  • Like
Reactions: Tom8823

twins333

Well-Known Member
Member
Joined
May 30, 2023
Messages
102
Trophies
0
XP
452
Country
Afghanistan
Its doesn't relate to the picofly.
It means the 3.3V doesn't turn off.
Picofly took the 3.3V from the pm ic.

The first thing you need to check, from what point is the picofly took the 3.3V. It might use the wrong point, but its less probable, since there are already guide in everywhere.

The second thing is check the pm ic, it could be partial broken. Theres no other way then replace the pm ic.
I think he already mentioned he sourced 3v3 from the emmc. That might not be a good thing.
 
  • Like
Reactions: Tom8823

thesjaakspoiler

Well-Known Member
Member
Joined
Nov 20, 2018
Messages
1,320
Trophies
0
Age
124
XP
1,944
Country
Afghanistan
Could that be faulty chip? Or something else like my mosfet? It's really bizarre that voltages stay active and prevent me from turning on my console unless I press long power button (which sometimes doesn't help and I have to open console to reconnect battery)
After a successful glitch, the rp2040 goes into some low power sleep mode where it removes the power from all the I/O ports and thus the led on the board will also go out.
There is somewhere a voltage line in the Switch that stays active in order to be able to turn on the Switch with the power button.
I wonder if some tutorial is telling people to use that point as the source for the 3.3v.
A while back someone said that he didn't like the fact that the rp2040 boards didn't have a full power off circuit and it eventually would drain his Switch battery. That would only happen if the RP2040 is connected to a power source that is always on.
 
  • Like
Reactions: Tom8823

Tom8823

Well-Known Member
Newcomer
Joined
Jun 22, 2020
Messages
78
Trophies
0
Age
36
XP
696
Country
Canada
Yes I'm taking my 3.3v from emmc board. I don't think I use wrong line because I tried turning on and off console at least 10 times and 3.3v stayed active only once. Normally it goes off when console is off. Maybe it really is problem with power IC.

And no I haven't tried another chip yet since I need to order one.
 

abal1000x

Well-Known Member
Member
Joined
Jun 5, 2022
Messages
1,132
Trophies
0
XP
1,629
Country
Gaza Strip
A while back someone said that he didn't like the fact that the rp2040 boards didn't have a full power off circuit and it eventually would drain his Switch battery. That would only happen if the RP2040 is connected to a power source that is always on.
Thats me i guess :D
I am not complaint when the switch off. I am complaint when the switch on, couldn't turn off completely rp2040.
But if the switch off, the picofly follows (off too).

I have 3 switch, the 2 switch i turn it off like 6 month, i kind of forgot, then when i turn on its still 90% battery.
The one i use oled, i have not use it for 1.5month and i test turn it on couple hour ago, and its still 98.5% from 99%.
Post automatically merged:

Yes I'm taking my 3.3v from emmc board. I don't think I use wrong line because I tried turning on and off console at least 10 times and 3.3v stayed active only once. Normally it goes off when console is off. Maybe it really is problem with power IC.

And no I haven't tried another chip yet since I need to order one.
AFAIK, its okay to take the 3.3v from the emmc.

The one who turn the 3.3v on and off is the pmic max77620.
I forgot read in what sites, saying about 2 stage of pmic when the switch turn on.
Unfortunately the datasheet is not being shared.
I have asked in here and in other forum, but no one have the datasheet.

Editted:
I read from here
https://www.retrosix.wiki/max77620-cpu-regulator


All the red are 1 line (3.3v rail)
a.png

b.png
 
Last edited by abal1000x,

Tom8823

Well-Known Member
Newcomer
Joined
Jun 22, 2020
Messages
78
Trophies
0
Age
36
XP
696
Country
Canada
Thank you but I think I will leave things as is. I've never reballed a chip in my life and the risk of screwing it up is too high. I can live with hard resetting my switch every now and then. Unless it stops booting up completely I ain't touching it.
 

thesjaakspoiler

Well-Known Member
Member
Joined
Nov 20, 2018
Messages
1,320
Trophies
0
Age
124
XP
1,944
Country
Afghanistan
Spent half an hour trying to fix *= only to realise the f*k*g rp2040-tiny clone's 47ohm wasn't soldered on properly from the factory 😵‍💫
Sometimes saving a few pennies gets me as well.
A dollar extra for a Waveshare is well spend.
Post automatically merged:

Thanks for mentioning that site!
A lot of info I have never seen on other sites.
Those online board views are also handy. I'd wish someone would make one of the OLED.
http://balika011.hu/switch/
 
Last edited by thesjaakspoiler,
  • Like
Reactions: Nephiel

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    SylverReZ @ SylverReZ: https://www.youtube.com/watch?v=xpLm0eXndNw