Notice: I am not receiving notifications for this thread. I didn`t realise people were still posting in it.

Please please accept my apologies if I haven`t replied to tags etc... I have no idea what is happening. I`m subscribed to this thread but I am not receiving notifications. Please inbox me if possible. Or tag me in another thread.

Its amazing that people are still checking all of this out. I thank you for all of the help and support I have received in this thread over this year.

Cheers. Matty.


A video showing a modchip in action. Thank you once again to @metaljay for providing this. This is what you can achieve by fitting a chip!

Section 1. Gather your software.

Get your chip software from THIS THREAD.
Follow the flashing instructions there...

Section 2. Removing USB port and unneeded LEDs. (Adafruit chips only)

• Next, we need to remove the USB port from the modchip. I recommend a heatgun or a rework station. Heat up until the USB port just lifts off the modchip.

• Do the same for the LED just to the right of the USB port.

See picture:

You are now ready to fit your device. Proceed to Fitting section.

Section 3. Fitting modchip to your Switch.
New Universal Method. All SAMD-based internal chips. If your chip is not supported and you cannot work it out, PM me.

Trinket M0.
Solder as laid out in the following picture

==================================================
Rebug SwitchME M0. Use Trinket files.
Solder as laid out in the following picture

==================================================
RCMX86 - Internal modchip version.
Solder as laid out in the following picture

==================================================
Gemma M0. Use Gemma files.
Solder as laid out in the following picture

==================================================
ItsyBitsy M0 Express. Use ItsyBitsy files.
Solder as laid out in the following picture

==================================================
Feather M0 Express. Use Feather files.
Solder as laid out in the following picture

BUILD YOUR OWN FROM A QFP ATSAMD21E18. Trinket equivalent pins.
Flash Trinket bootloader using OpenOCD via serial pins SWDIO / SWDCLK. Fit a reset switch somewhere... Or going to power / wake (aka method 2). If building for external use, it is good practice to fit a third capacitor between 3V & GND. This is deliberately vague and ambigious, as this needs research and you need to know what you are doing.

Link for setting the Pi up with OpenOCD: HERE
Raspberry Pi OpenOCD image in downloads section or HERE

Alternative Solder Points

Credit to @consolex for original pic. I`ve added alternative points to solder to:

Credit to @pyorin for this much tidier version showing the same info as the above one!

Replacement Parts List

Spoiler: Parts

Ok... So you have damaged your switch soldering your chip in. Not to worry.

First things first, DO NOT BRIDGE THE CONTACTS HOPING TO REVIVE YOUR SWITCH. With resistors, you may possibly get away with this, but with the capacitors listed below, if you jump these points, you will make a nice short-circuit to the PMIC and / or the M92T36, killing them instantly. Don`t do it.

OK... I`ll list these parts with METHOD 2 & 3 TRINKET PIN NUMBERS and the values of the components they solder to.

TRINKET 3V (POWER SUPPLY) - 2.2uF 0402 size MLCC capacitor. Voltage unimportant as long as it is over 6.3v
TRINKET PIN 2 (POWER ON RESET - goes to pin 5 on M92T36)- 4.7uF 0402 size MLCC capacitor. Voltage unimportant as long as it is over 6.3v
TRINKET PIN 0 (VOL+) - 150R (150 ohms) 0201 Thick Film resistor. 50mW
TRINKET RESET (SWITCH POWER BUTTON) - 150R (150 ohms) 0201 Thick Film resistor. 50mW

I recommend RS components.

FAQ

Q - How do I boot the switch into APX (RCM) mode?

A - You need to short out pin 10 on the right joycon rail to GND with a jig or modded joycon or paperclip (not recommended... Buy a jig you cheap-ass gyppo). Once shorted out, hold down vol+ and power. The switch screen should be off... Plug into your PC and it should recognise a APX device. Well done. You are in RCM.

Q - What glue should I use?
A - Only glue if necessary! Ideally if your soldering is of sufficient quality and your wire is thin enough, you don`t need glue. I use a bit because I am OCD. Anyway, use Epoxy. It`s what I use. Gives you some working time, is solid. Superglue makes a mess DO NOT USE SUPERGLUE. The only thing super about it is how it melts things. Epoxy won`t stick to the shield long-term, so bear that in mind. Pure Acetone will remove epoxy. Acetone tends to remove / melt anything to be warned. CHECK YOUR GLUE WON`T GO CONDUCTIVE OVER TIME - LOOKING AT YOU SCAMSUNG! The combination of heat cycles and absorbing of moisture can turn adhesive into a high-impedance connection!

Q - What size wire should I use?
A - I use AWG40 magnet wire or AWG30 Kynar. AWG40 goes onto components easier... And if you snap it, chances are the wire will snap and not the trace / component.
A2 - You can also use AWG30. I recommend Kynar wrapping wire but any will do. Looks nice, good resistance to elements, tidy. Nothing thicker than AWG30. You are just causing yourself more headaches. Trust me.

Q - Is AWG40 thick enough?
A - Yes. AWG40 is good for around 90mA.

Q - which methods do you recommend?
A - Connect all the straps...

Q - how do you recommend to set it up?
A - Fusee Suite. Search for Fusee Suite or go to link at top of this OP.

Q - My switch is flat and won't turn on.
A - Have you got the charger connected? Disconnect it or your switch won't boot! Boot to a payload (SX loader/Hekate), reconnect charger and leave on the payload menu and charge. Leave for 15 minutes and switch will start normally. It will continue charging one booted.

Disclaimer:
You have only yourself to blame. This voids warranty. This may or may not get you banned from online services. If it does, you got yourself banned. I`m not responsible if you kill your switch / your first-born with any of this in this post. I`m not infalliable. I`m partly senile. Do your own research. Kids, get bill payers permission before you attempt even using a screwdriver.
NUTSHELL: Don`t come having a go at me because you fooked your £300 console up. I`ll do my best to help you though if you do, Just don`t blame me.

Credits to Quantum-Cross, Atlas44, @Ninoh-FOX , @jcrorxp , @tecfreak, @mooglazer, @subcon959, @64Dp128k, @mikeleuskaldunak, @M-O-B, CTCaer, @evilsperm, @consolex and everyone else for valuable input.

IF YOU REQUIRE SUPPORT, IF YOUR CONSOLE ISN`T WORKING CORRECTLY... PLEASE POST A HIGH RESOLUTION PICTURE OF YOUR INSTALL. You might think it isn`t your soldering, but in all cases with the new methods, it is bad soldering. So, please post a picture.

A BRIEF WARNING - PLEASE READ

Spoiler: READ THIS

THIS MOD IS NOT FOR THE FEINT OF HEART. WE ARE SOLDERING TO TRACES AND COMPONENTS ON THE FRONT SIDE OF THE BOARD TO SAVE HAVING TO REMOVE THE BOARD AND SOLDER TO TESTPOINTS. IF YOU ARE STRUGGLING, OR THINK YOU ARE GOING TO STRUGGLE, PLEASE PLEASE SOLDER TO THE TEST POINTS NOTED IN THIS AND OTHER THREADS (YOU WILL NEED TO REMOVE THE MOTHERBOARD). DOUBLE - TRIPLE CHECK EVERYTHING. YOU HAVE BEEN WARNED!!!
Good soldering skills are needed!
A magnifying glass is needed!
Good soldering iron needed - ideally with a 0.3 conical tip. No more than 30w!
SECURE YOUR WIRES PRIOR TO SOLDERING. Stick them down with double-sided tape.
Only use glue if you need to and glue wires after soldering. Don`t glue the solder to the component!
Put the tiniest amount of glue on the PCB mask only. Never on components. Use a cocktail stick for more glue control!!!
Take a look at alternative solder points to get you out of the sh*t if you do rip something off the board
If you aren`t the best at soldering, then think very carefully about connecting to pin 6 capacitor (the one in these new methods). If you rip this pad, you WILL NEED TO REMOVE YOUR BOARD and run from a testpoint.

 

[popy]

Pretty much.

You need Arduino and adafruit sand support libs, flashstorage and dotstar libs.

I'll build you one when I get home. Give me an hour

Thanks, already built it, but how can ill make an UF2 out of the elf?

 

[mattytrog]

Thanks, already built it, but how can ill make an UF2 out of the elf?

Chip in switchboot mode. Plug in. Select your chip from be menu. Select com port. Flash straight to chip.

 

[popy]

Chip in switchboot mode. Plug in. Select your chip from be menu. Select com port. Flash straight to chip.

thanks, but i want to get the UF2.
My switch isnt here at the moment :-)

 

[popy]

ok, got it iwht: https://github.com/lancaster-university/codal/blob/master/utils/uf2conv.py
Firmware working.
Try to find a fix.

pOpY

 

[popy]

@mattytrog
Have tried tod the following:

void wakeup_usb() {
delayMicroseconds(500000);
//Set flag that loop() checks and if 1 it resends the payload
ulLookForTegraBeforeSleep = 1;
}

and

void loop()
{
//Should we send the payload?
if(ulLookForTegraBeforeSleep == 1)
{
//Yes, do it :-)
ulLookForTegraBeforeSleep = 0;
lookfortegra();
}

//Sleep
sleep(1);
}

Sadly, does'nt seems to work.
Any ideas?

 

[mattytrog]

@mattytrog
Have tried tod the following:

void wakeup_usb() {
delayMicroseconds(500000);
//Set flag that loop() checks and if 1 it resends the payload
ulLookForTegraBeforeSleep = 1;
}

and

void loop()
{
//Should we send the payload?
if(ulLookForTegraBeforeSleep == 1)
{
//Yes, do it :-)
ulLookForTegraBeforeSleep = 0;
lookfortegra();
}

//Sleep
sleep(1);
}

Sadly, does'nt seems to work.
Any ideas?

Yes. The reset is called from void wakeup. To do what you need, you basically need to reset all defines, start from void firstboot, then normal straps, set interrupts then look for tegrarcmsmash. I'll do it for you tonight. Trust me... I'm not the most efficient c programmer. I had a 25 year break from c and assembler.

 

[popy]

Yes. The reset is called from void wakeup. To do what you need, you basically need to reset all defines, start from void firstboot, then normal straps, set interrupts then look for tegrarcmsmash. I'll do it for you tonight. Trust me... I'm not the most efficient c programmer. I had a 25 year break from c and assembler.

I have removed the 500ms delay in wakeup_usb():

void wakeup_usb() {
//delayMicroseconds(500000);
dropstraps();
normalstraps();
SCB->AIRCR = ((0x5FA << SCB_AIRCR_VECTKEY_Pos) | SCB_AIRCR_SYSRESETREQ_Msk); //full software reset
}

Now it works on my switch like the following (with autoRCM for safety reasons):

• Switch is powered off
• I'll insert usb cable
• Switch wents black and trinket power led on
• unplug usb
• SX OS screen pops up
• Shortly the CHarging icon in the left < is this a problem!? Meaning that Big-N bootloader started?
• CFW (SX OS) is booting and working

My theory here, SX OS payload or loader is triggering the USB wakeup during first poweron, than theres the delay and then the straps are pulled during SX OS loader boot.
Does this sounds plausible?
Why is there a delay?

pOpY

 

[popy]

Have also treid something like this:

void loop()
{
if(ucTest)
{
ucTest = 0;
lastCheckTime = 0;
storedpayload = stored_payload.read();
storedmode = stored_mode.read();
newpayload = storedpayload;
newmode = storedmode;
startblink = 1;
dropstraps(); //pull straps low
normalstraps();
firstboot(); //get flash memory status. If invalid, make valid.
mode_check();
lookfortegra();
}


Without success.
I am trying now to reduce the delay...

 

[popy]

@mattytrog
I have done timing tests with my switch and the wakeup_usb() delay (which was 500ms in your code and working on your switch).
With the following results:

250ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
350ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
400ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
425ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
437ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
443ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
446ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
450ms -> NOT OK -> SX OS menu -> press CFW in menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)

So it seems an timing issue to me -> your switch is different than mine on same FW (6.2.0).
As you can see above it is working under 450ms for me also, no SX menu.
So here are my final questions:

• How did you determine this delay?
  Do you think we can reduce it to 250ms? (so we have ~200ms on my switch safe time)
  
  
• Is it normal that the battery icon is displayed after pulling usb cable and SX OS splash screen?
  Or is this a sign that Big-N bootstack is running and can burn fuses?
  I have done my tests with autoRCM to prevent burn fuses if i fuck something up in the code
  Do you think its safe for me todo my tests without autoRCM?

Thx
pOpY

 

[popy]

@mattytrog
I have just done it -> disabled autoRCM, 250ms delay in UF2 and tested the following:

• 5x: Boot normal -> SX OS CFW is always started (without boot menu)
• 5x: Restarted horizon 5x times -> SX OS CFW is always started (without boot menu)
• 5x: Press and hold vol+ after short PWR press -> SX OS menu is shown
• 5x: launch briccmii from SX OS menu: its waiting for keys correctly and not doing any action itself (like it was before when vol+ was pressed -> unbrick)
• 5x: power off switch -> insert unsb cable -> remove usb cable -> SX OS CFW is always started (without boot menu)

And all that with no burnt fuses .
I am on FW 6.2.0 which has 8 burnt fuses) but briccmii reads 6, which stands for firmware 5.0.0/5.1.0
So with 250ms in the function wakeup_usb all is working as it should for me.

I have activated autoRCM to be 999999% safe

pOpY

 

[mattytrog]

@mattytrog
I have done timing tests with my switch and the wakeup_usb() delay (which was 500ms in your code and working on your switch).
With the following results:

250ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
350ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
400ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
425ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
437ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
443ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
446ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
450ms -> NOT OK -> SX OS menu -> press CFW in menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)

So it seems an timing issue to me -> your switch is different than mine on same FW (6.2.0).
As you can see above it is working under 450ms for me also, no SX menu.
So here are my final questions:

• How did you determine this delay?
  Do you think we can reduce it to 250ms? (so we have ~200ms on my switch safe time)
  
  
• Is it normal that the battery icon is displayed after pulling usb cable and SX OS splash screen?
  Or is this a sign that Big-N bootstack is running and can burn fuses?
  I have done my tests with autoRCM to prevent burn fuses if i fuck something up in the code
  Do you think its safe for me todo my tests without autoRCM?

Thx
pOpY

Right... Just got in. Going to be a long night tonight. Got 4 water damaged handsets come in and a Yaesu 857 Transceiver to repair and align

Anyway... Lets press on.

No. Fuses cannot be burned.

I chose 500mS to allow for faulty cables. Some cables have breaks. If they are pulled out slowly, data pins could be connected while pwr + gnd pins are not connected or visa versa.

The testpoint that we are using is actually an input to the BQ24193 for a battery thermistor. The signal we are using is the bias to this thermistor.

I can change the value to suit. I plan on working on the code substantially tonight at some point.

Yes. It is normal that the battery is connected. To confirm, one can disable the straps (thus burning fuses) and plugging in to USB when the power is off. Same behaviour.

Just to clarify... Don`t piss around with the switchboot code. That is saving your fuses and like I said... Has been tested thoroughly. As long as you are using the both file of switchboot, you are safe.

But yes. It isn`t crucial the usb delay is 500mS. It was just a ballpark figure to provide some "bounce" protection if all pins in the USB lead are not connecting properly. Thats all.

Experiment as you wish.

--------------------- MERGED ---------------------------

@mattytrog
I have just done it -> disabled autoRCM, 250ms delay in UF2 and tested the following:

• 5x: Boot normal -> SX OS CFW is always started (without boot menu)
• 5x: Restarted horizon 5x times -> SX OS CFW is always started (without boot menu)
• 5x: Press and hold vol+ after short PWR press -> SX OS menu is shown
• 5x: launch briccmii from SX OS menu: its waiting for keys correctly and not doing any action itself (like it was before when vol+ was pressed -> unbrick)
• 5x: power off switch -> insert unsb cable -> remove usb cable -> SX OS CFW is always started (without boot menu)

And all that with no burnt fuses .
I am on FW 6.2.0 which has 8 burnt fuses) but briccmii reads 6, which stands for firmware 5.0.0/5.1.0
So with 250ms in the function wakeup_usb all is working as it should for me.

I have activated autoRCM to be 999999% safe

pOpY

If you have done your testing with autoRCM enabled, then that is not much good. The 500mS works fine for me but I`ll commit 250mS

 

[mattytrog]

@popy

Going back to your previous point earlier about just pushing payload... I think I`d rather keep it as it is. The most obvious reason is that when the console is off and it is unplugged, because there is no autoRCM, the Nintendo bootloader will run and burn fuses.

So that is a big nono. That defeats the object of this exercise. How is the bootloader going to trigger RCM? It can`t.

Resulting in normal boot, burning fuses.

Nice idea though.

Those straps have to be grounded STRAIGHT AWAY. That is only possible from running the bootloader first.

However, I`m putting code "switches" in (#define ENABLE_USB_STRAP) and maybe add a new couple of "modes" to enable or disable the strap with a button press.

And changing the delay to 250mS. Thank-you for the suggestion!
I want that delay there just as a "debounce" as I said earlier in case a wobbly connector causes problems, resulting in a device stuck in RCM.

I`m not happy about it as it contradicts pulling the straps low straight away. Think I might just do it on falling.

Fancy testing?

 

[popy]

Right... Just got in. Going to be a long night tonight. Got 4 water damaged handsets come in and a Yaesu 857 Transceiver to repair and align

Anyway... Lets press on.

No. Fuses cannot be burned.

I chose 500mS to allow for faulty cables. Some cables have breaks. If they are pulled out slowly, data pins could be connected while pwr + gnd pins are not connected or visa versa.

The testpoint that we are using is actually an input to the BQ24193 for a battery thermistor. The signal we are using is the bias to this thermistor.

I can change the value to suit. I plan on working on the code substantially tonight at some point.

Yes. It is normal that the battery is connected. To confirm, one can disable the straps (thus burning fuses) and plugging in to USB when the power is off. Same behaviour.

Just to clarify... Don`t piss around with the switchboot code. That is saving your fuses and like I said... Has been tested thoroughly. As long as you are using the both file of switchboot, you are safe.

But yes. It isn`t crucial the usb delay is 500mS. It was just a ballpark figure to provide some "bounce" protection if all pins in the USB lead are not connecting properly. Thats all.

Experiment as you wish.

--------------------- MERGED ---------------------------


If you have done your testing with autoRCM enabled, then that is not much good. The 500mS works fine for me but I`ll commit 250mS

Thanks for clearing things up. My tests was wothout autoRCM! Just activated it afterwards.
So yes, 250ms is good here.

pOpY

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

 

[mattytrog]

@Markeyx guess what

 

[popy]

@Markeyx guess whatView attachment 154925

Whats this?

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

 

[mattytrog]

Whats this?

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

Oh... Just a switch which eMmc had a few issues!

Posted in wrong thread actually.

 

[popy]

Oh... Just a switch which eMmc had a few issues!

Posted in wrong thread actually.

[emoji12]

Do you planing to reduce the 500ms wakupup_usb to 250ms?

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

 

[Dougiejones]

Hi,

if you permit here's my feedback with the new universal method + Simple-UF2 v0.9.4.uf2.
I'm facing the same issue as popy that is only booting at the SX OS Option menu from startup.

My setup :

• Neon Switch from stock upgraded onto 6.2.0 ofw
  
• Joycon modded
• Trinket M0 flashed with switchboot bootloader then Trinket_Rebug_Both.uf2
• Vol+ strap and USB disconnect strap fitted

If this could help

 

[popy]

Hi,

if you permit here's my feedback with the new universal method + Simple-UF2 v0.9.4.uf2.
I'm facing the same issue as popy that is only booting at the SX OS Option menu from startup.

My setup :

• Neon Switch from stock upgraded onto 6.2.0 ofw
  
• Joycon modded
• Trinket M0 flashed with switchboot bootloader then Trinket_Rebug_Both.uf2
• Vol+ strap and USB disconnect strap fitted

If this could help

Try the attached one. This is my modded 0.9.4 with 250ms delay on wakeup_usb() function.
Be sure do have the following:

• Fit all three straps (Joycon/RCM, VOl+ & USB)
• Flash the SWITCHBOOT both
• Flash my attached file

This works for me reliable and also without autoRCM and WIHTOUT burning fuses
PS.: i'll take no responsibility

pOpY

 

[Dougiejones]

Try the attached one. This is my modded 0.9.4 with 250ms delay on wakeup_usb() function.
Be sure do have the following:

• Fit all three straps (Joycon/RCM, VOl+ & USB)
• Flash the SWITCHBOOT both
• Flash my attached file

This works for me reliable and also without autoRCM and WIHTOUT burning fuses
PS.: i'll take no responsibility

I've tried your TRINKET_REBUG_SIMPLE_UF2_V094_250ms.UF2 and it works like a charm

Just a question. Why your 250_ms.UF2 is half the size from the original for just timing change ?
Did you cut so much in the code ?

@popy : Thank you for your tests and bug ascent
@mattytrog : Thank you for your amazing work