Picofly installed worked first time niw switch fried

Looks fine afaict.

I’ll wait for your measurments again just to be doubly sure but based on your readings prior it is suggesting the SoC is at fault (In which case there is nothing you can do) I mean you could maybe ensure modchip is good physically (update the firmware etc) solder it back up and see if you get anything onscreen, though, even if you do (which I don’t think you will) , I’m not sure how long it’d last given the faults we’ve identified.

That being said, I suppose there is a very very very slim chance it’s something else on 1V8PDR which could be causing the fault but given the amount of things which have a connection with this rail (pretty much everything on the board) you basically have to strip the board down to virtually nothing to find it (or go round with your meter in resistance, maintain consistent ground, and check all locations where the rail shows up and see which location it measures at it’s lowest relative to ground to find the most likely candidate) but I think you’ll still wind up back at the SoC :frowning:

Trouble I have here is what caused the fault in the first place. Solder joints from the OP all looked fine and we have to assume he soldered to the correct locations given that the modchip was working initially… even if he shorted out 1V8PDR or 3V3PDR to ground (worst case) then it shouldn’t (or maybe I should say wouldn’t typically) cause permanent damage like this (we have seen cases where 1V8PDR was near dead short and console is still able to boot and likewise cases where 3V3PDR is shorted and once the short is clear the board still works) which only leads me back to my thoughts on the modchip design flaw I mentioned, no level shifting register on the MCU itself to change the I/O LL and no dedicated circuitry on the “PCB” to do it, as such, ordinarily 1.8V IOis forced upto a 3.3V LL - which might not be a problem ordinarily given the shear speads of the EMMC protocol (not always high switching very fast during data r/w) but if the modchip has a bug / glitch and the I/O in question is stuck logic high and/or depending on the state of the I/O when no FW is flashed on the modchip and/or during an update… In which case (IO stuck high) I don’t see the rest of the Switch board tolerating it for long.especially the EMMC or SoC. For anyone reading this who is considering getting a modchip, be very cautious.

Let me know which measurements you would like again and il get right onto it so that we can make sure

The ones above :+1: :+1:

If your talking about these, then sorry you’ll have to figure this out, I could give you a few areas but the reality is the rail shows up everywhere and as I say I’m pretty sure you’d find yourself back at the SoC :frowning:

I can always try at least for educational purposes who ever reads this can see the areas. If you can provide me the areas and i can take readings

You are able to locate these all on your own :slight_smile: (Ideally you’d use a known good board but given your board this rail is a soft short you can use it in this case) put your meter in continuity, one probe on 1V8PDR (the side of the inductor pad with the 180 odd ohm short) and find the other locations (based on the beeps) by probing around the board (for example there is a 1V8PDR cap on the SoC) after you’ve found a few points, as mentioned, find a consistent ground throughout and measure the resistance to ground at the locations identified and see which one is the lowest.

absolutely :slight_smile: :+1:

Another way of doing it (if you meter has the capability) is put one probe on ground, and the other at the 1V8PDR inductor pad (side with the short) and zero out your meter (again assuming it has the capability) then you can go looking for the other locations of 1V8PDR and with your meter now zeroed, values hovering around the zero mark (for example you identified one of the locations at the tespoint just prior to the EMMC connector) - this is a good way to cheat some extra “resolution” on your meter and simplifies things, as your only interested in negative readings at that point (for example -01.40 ohm or -00.03 again, just examples) this is all just like that game we used to play as kids (I forget the name) but ya know, you hide the thing then say freezing cold, cold, warm, getting warmer, hot, scolding hot :smiley:

Will give it a go

I was wondering if the soc is the issue if i got the hwfly mod kit would that make any difference

No, I don’t think so, the assumption atm is the SoC if fried :frowning:

I have actually just ordered 2 of these from china. Not because I want to mod a console, but because a number of my threads ended up with needing to get into hetake to go any thurther. So if i work out whuch boards those were and try,i will let you know! Maybe we can work out a bit more aboht what they are doing.

1 Like

Yeah they are pretty handy for diagnosis purposes on patched/Mariko

Which version of the modchip did you go for? In the case of the OP (If I’m emembering right - long thread) he went for basically the standard RP dev board, in this case it’s far more reasonable to assume it didn’t have the FW pre-installed required for exploit and/or it would be far easier for the FW to mistakenly not be flashed (by the seller). I’m curious in these instances what the default IO behaviour is on these development boards, are they active high or active low when they are powered up (via USB for example) and/or if it does come preflashed with an older FW what the behaviour is. (this might explain a lot of the issues we’ve been seeing related to the modchip/s)

I suppose all of the above could also apply to the other variants too.

That would be good :+1: better yet if you have a scope or logic analyser, connect it up to one of the EMMC signal lines (Unfortunately it might be the case with the proper FW it would need to be connected to an actual Switch for the lines in question to become active high if it needs to have performed the “glitch” prior, but worth checking without connecting to Switch prior) and use oh, let’s say a 1.8V trigger, and see if the signal peaks at 3.3V (which I think it will) and if any of the other points apply (stuck logic high for example in some potentially no FW, old FW cases) which we’d be able to see from waveform / LA capture.- Though I am just guessing for a lot of these cases / scenarios, I could well be wrong :slight_smile:

I went for the hwfly boards that happen to use the pi chip on them, rather than getting a dev board.

Ah, be interesting to see when it turns up :slight_smile: let us know your findings :+1:

Maybe a lost cause board which happens to have a good EMMC would be best first port of call for first test, just in case :slight_smile:

They have already arrived, but i will need to go through my boards again to findva good candidate. Will let you know.

1 Like

Ok so update i got the hwlfy mod chip and installed it correctly and at first it wash flashing blue but no green and now it shows red static

I read up online means

Red error means either bad CLK, DAT0, or CMD connection, or bad eMMC.

Can we still do something to save it or is it still the same scenario

Which is to be expected unfortunately based on your prior measurments :frowning: one of the key rails for the EMMC is being pulled low, so not much of a surprise communication isn’t working (together with other rails on the mainboard being skewed)

tbh I think this one is a donor at this point :frowning: think the SoC is toast

Ahh well donor it is then