yeah i know more or less ,just wanting to clear my paranoia. Its still shocking you know, that you can fk up a board in an instant.It´s ok, you just break a fixing anchor
Post automatically merged:
By the way, any of you guys had problems with consoles where you forgot to put the thermal pad back on the charging chip?
In this case Picofly didnt work. Installing a HWFLY Modchip fix this issue. What shows u the emmc info?
Your previous solder already okay.
This would be problematic though.
If you change the mosfet, but still same, then the problem might lay on other thing. That gate cable try to change it with plastic insulated cable, just for concept only. Maybe when picofly send the 3.3v to switch the mosfet, it is not delivered correctly.
And make sure its connected to the right pin in the picofly board. Sometimes we make a silly mistakes. Human could get tired.
It booted to ofw, Im gonna fix it this soldering job. I know it looks funny
Post automatically merged:
Got it working! thanks @Viktorsilva
Attachments
Last edited by DumbSolder,
Just had a customer bring in the switch for a picofly install. He failed to mention that he attempted the mod and tore the cap off of sp1 and sp2. Was able to replace the sp1 but sp2 has a torn pad. Is there an alternative? Can I just connect to sp1?
Post automatically merged:
Answered my own question. Was able to just use sp1 with a single mosfet.
Attachments
Last edited by BlueBeans,
Anyone experienced this before? Whenever i boot to OFW/CFW/turn off console while in hekate i get this line for 0.01 seconds. What is the cause? I dont get this in OFW/CFW while screen is black (turned on,like loading game). Pins in the display connector looks great,and the cable also?
Thanks for the ideas. Would a bad connection to the mosfet also trigger ==* ==* ==*? Is it a general "check the mosfet connection", or something else? Is there an order that the boot code goes in, so I can rule out other connection errors?
Swapping the gate wire with a thicker enameled wire didn't change the result, so I'm running out of obvious things to troubleshoot.
Would adding the SDA and SDL wires help bypass this?
I'll get a picture later, but I'm using the 40awg magnet wire for the other connections between the pico and the motherboard. I'm using the SEEED board with the detection pins bridged with solder, following the 6.4 PDF guide from here.
have you tried checking the chip? I had the same issue before and it turns out that the chip was bad. Spent hours of debugging, changing wires etc. but it was the chip that is busted after all.
Picofly firmware send the signal through the gate to the mosfet, and the mosfet bridge the DS, then the firmware will read the byte stream on the CMD line. With that error means the bytes read from the CMD line is normal as if no mosfet in there 'stealing' the power goes to the cpu.
So from here, the probability of the causal, as far as i could list:
1. The mosfet broken.
2. The gate line is problematic.
3. The D or S line which connected to the CPU power (via the capacitor) is problematic.
4. Somehow the CMD line is unstable. Theres check on CMD line voltage, in the beginning. And its passed (OK). Theres also reading CMD line bytes when first upload the loader to the emmc through Dat0 (white led), it also passed. So the probability that this is the cause of the error is low.
5. The picofly (rp2040) problematic cant send the gate signal.
6. The connection from the cap to the cpu are problematic. This also low probability, except you drill something around that place which cut something off. If its really is, then you need to use the cpu caps.
7. Somehow that cpu's batch has different glitch behaviour than others.
The sda and scl as long as i know is unstable. And i don't know whether the last firmware are well tested using sda and scl. I remember in previous time, we could simply click the reset button on the rp2040 when the black screen before (or after) the nintendo logo, and it glitched. That leads to the sda scl method, the glitch are done on low voltage.
This was an excellent writeup, thank you.
From your list, I believe I might have messed something up with the capacitor. When I was trying to get more solder on to fix the first cold joint, I accidentally covered the cap in solder + flux. I used my wick to clean it up, but perhaps there's some still solder stuck underneath that is bridging the cap.
Are these caps easy to take off?
If not, I'll switch to the front side and move on.
I've had 2 cases of purple screen, obviously on OLED and both solved by changing the 4.7K resistor even if intact given my experience. In my opinion it's something that happens at the first boot when you have the white light on the rp2040-zero
@MrScopi , i allready told you what is your problem but i guess you didnt understood.
I already had this problem and even created a topic mentioning it but as I didn't get help from anyone I had to figure out how to solve it on my own because I bought 150 Mosfets. Most users on this forum use flex cables that solder directly to the cpu capacitors and as they have pull-down protection resistance, the mosfet is never in open mode. However, handling the mosfet directly can leave the Gate open to the Drain. And it is in this situation that you will receive the famous ==* error.
Well, I decided to take a new MOSFET out of the packaging and leave it in open mode so you can understand what I'm saying. Notice how in this image the Source is open to the Drain:
If I install the mosfet in this state, it won't work. The internal diode is open and allows the passage of electrical current between the Source and Gate point. If you do, Picofly will give the error long long short yellow light (==*)
But it is possible to close the internal diode again, passing residual energy (just use the multimeter in diode mode) by placing the red (positive) tip on Gate and the black tip on the Drain. And the result is:
Now Mosfet is ready to be installed again .I made a short video on how to close the Mosfet again. Maybe it will be easier to understand if you watch the video. These MOSFETs have proven to be very resilient. In all my installations I only damaged a diode once and it was my fault because I insulated it poorly and it touched the metal protection of the CPU (it even smoked).
Measure the continuity on your mosfet and tell me if you have the Source open for the Drain. If so, you discovered your problem.
Post automatically merged:
There are many situations where people have damaged the cpu capacitors (SP1 & SP2) and the installation still worked. However, work worthy of a professional requires replacing the damaged capacitor. You can find an identical capacitor on the bottom of the RP2040 Zero:Just had a customer bring in the switch for a picofly install. He failed to mention that he attempted the mod and tore the cap off of sp1 and sp2. Was able to replace the sp1 but sp2 has a torn pad. Is there an alternative? Can I just connect to sp1?
Post automatically merged:
Answered my own question. Was able to just use sp1 with a single mosfet.
Post automatically merged:
Another one come back from the deadIt booted to ofw, Im gonna fix it this soldering job. I know it looks funny
Post automatically merged:
View attachment 420493
Got it working! thanks @Viktorsilva
Last edited by Viktorsilva,
Its not possible. If its bridge, the device wont power on, since the cpu doesnt get the power, and the power ic which supplied it might burn because of excessive current flows.
Difficult to answer.
Generally its not easy.
That is the whole reason why i said the back mosfet is safe compare to the front cap. Because its not easy to take it off (or broke the pad), since its big. If its small cap, just put lot of solder until it cover the whole body, it will easily take off (and the caps pad are easily broken).
Post automatically merged:
Actually theres no need to switch the gate off manually.@MrScopi , i allready told you what is your problem but i guess you didnt understood.
I already had this problem and even created a topic mentioning it but as I didn't get help from anyone I had to figure out how to solve it on my own because I bought 150 Mosfets. Most users on this forum use flex cables that solder directly to the cpu capacitors and as they have pull-down protection resistance, the mosfet is never in open mode. However, handling the mosfet directly can leave the Gate open to the Drain. And it is in this situation that you will receive the famous ==* error.
View attachment 420621
Well, I decided to take a new MOSFET out of the packaging and leave it in open mode so you can understand what I'm saying. Notice how in this image the Source is open to the Drain:
View attachment 420622
If I install the mosfet in this state, it won't work. The internal diode is open and allows the passage of electrical current between the Source and Gate point. If you do, Picofly will give the error long long short yellow light (==*)
But it is possible to close the internal diode again, passing residual energy (just use the multimeter in diode mode) by placing the red (positive) tip on Gate and the black tip on the Drain. And the result is:
View attachment 420624
I made a short video on how to close the Mosfet again. Maybe it will be easier to understand if you watch the video. These MOSFETs have proven to be very resilient. In all my installations I only damaged a diode once and it was my fault because I insulated it poorly and it touched the metal protection of the CPU (it even smoked).
Measure the continuity on your mosfet and tell me if you have the Source open for the Drain. If so, you discovered your problem.
Post automatically merged:
There are many situations where people have damaged the cpu capacitors (SP1 & SP2) and the installation still worked. However, work worthy of a professional requires replacing the damaged capacitor. You can find an identical capacitor on the bottom of the RP2040 Zero:
View attachment 420634
Post automatically merged:
Another one come back from the dead
The picofly will pull down the gate when its on.
The problem might occur if the gate line disconnected and the gate in on state, the mosfet might burn, since the picofly can't pull it down.
https://github.com/rehius/usk/blob/6530fd9fe58980ea03d47905bad5e871b9439b7a/board_detect.c#L65
Its pulled down right after the picofly firmware booting up.
I believe that theoretically it should do it, but I guarantee you that if you install the MOSFET with source open to Drain, Picofly will not glitch and give the error ==*. I already tried it
Measure the continuity on your mosfet and tell me if you have the Source open for the Drain. If so, you discovered your problem.
Thank you again. I did check both the old mosfet and my new one, and both prior to installation did not have Source open to Drain. So they should have been OK to go.
After installation, I have continuity between Source and Drain -- this confuses me and makes me wonder if I have a short somewhere else. But those two sides of the cap have continuity before I install the mosfet, so for all I know the continuity path is via the cap and not the mosfet IC.
Glad to know that "shorting" the cap would be more obvious that just not glitching! I suppose at this point I might as well try swapping out the picofly boards themselves soon. I'm reasonably certain all my connections are correct, but I won't be back in front of the switch until Monday-ish.
Thanks again!
Similar threads
- No one is chatting at the moment.
