Here are some incomplete notes of the eMMC booting and attempt to find a stage of boot that confirms 100% if the eMMC is bad/corrupt in terms of not giving the Switch its desired data to pass on to second stage boot.

Here are the pins you can use to probe. The only real important pins for basic testing of activity are below. We just want to see the clock is active and the eMMC is sending data at certain times.

Make sure your console is booting to at least first stage boot, and your current draw is usually close to the 200mA range at the point of eMMC activity.

Use an oscilloscope to probe the eMMC clock pin, which should be running a clock signal at 24MHz (12 nanoseconds per cycle) and 1.8V (with peaks showing just over 2V).

The clock will run 100% of the time while the system is on, even if there is no eMMC or a bad eMMC, it is a direct line from the 24MHz clock. You should always see this signal present.

The data pins (any of them) are perfect for showing the activity and stages of boot of the console. But for these scopes we used the second from bottom DATA pin (so third data down).

There appears to be 3 stages of boot, with a small one between the first and second stage boot, which I think is just a security check.

Set the scope to 1 second per division to see almost the entire cycle of boot. Have your oscilloscope touching the data pin on the eMMC before powering on the console, as this boot cycle happens only once so if you are not probing when powering up you will miss it.

Here is what a fully successful working eMMC and full console boot looks like on the 3rd data pin down.

The important part that is different between a successful boot and a bad/wrong eMMC is the first stage boot. If we zoom in we can see more detail.

For ease of reference I have labelled the sub-sections of the first stage boot area as F1, F2, F3 and F4.

Let us zoom in once more right into the F1 section of the first stage boot, which is what we are interested in.

This F1 block on a successful boot will pulse for around 20 pulses of data, and a total of 2 milliseconds in time. Then it will do nothing and stay high for a period before going into F2, F3 and F4 stages.

As the eMMC is tied to the console and cannot be replaced or swapped while maintaining the ability to run the stock Nintendo firmware (you can run RCM boots with any eMMC, just not official Nintendo firmware), it is important to identify when the wrong eMMC is used, or a bad eMMC (failed/corrupt data or bad connections perhaps).

The same console with a successful boot, with an eMMC from another console will only reach the first stage boot F1. It will not get to F2 sub-phase of the First Stage Boot.

If we take a look at F1 at the same time divisions as the working boot above, you will see F1 lasts much longer, and has a distinctive 19 short pulses followed by longer pulses, then short and long until it settles on outputting all long pulses for around 100 milliseconds. In contrast a successful F1 boot is 2 milliseconds.

My suspicion here is this is an ID check that confirms the encrypted information in the eMMC matches between the eMMC and console, and if that fails, it asks for the information again several times until giving up as a failed boot.

Either way, the tell tail sign of a bad read/wrong eMMC data seems to be this pattern of F1 being much different with short bursts then long.

If you see a failed boot like above, just constant repetitive pulses on the data line, it can also be from a corrupt BCT data bit. This can happen from a crash, at random, at low battery or directly from someone hacking the Switch and enabling AutoRCM.

Checkout the RCM Diagnostics page to confirm if its bad eMMC or just corrupt BCT.

The issue can be fixed by injecting Hekate and disabling AutoRCM which recovers the BCT data.

In short, probe the 3rd data pin down on the eMMC board, set your multimeter to 50 milliseconds per division with a trigger of 1V, turn on the console and look for the above comparison between successful vs failed eMMC boot.

If you remove the eMMC completely, the system will still boot to the same stage (first stage boot) but there will be no activity at all on any of the data pins.