See below for updates.

IF YOU BREAK YOUR BOOT0 PIN. DO NOT DM ME ASKING FOR HELP. THAT'S IT. YOU BREAK THAT PIN AND YOU CANT FLASH. YOUR CHIP IS STUCK WITH WHATEVER HWFLY PUT ON IT


Pre-requisites:

---

• Raspberry Pi Zero W
  • You may use another flasher if you desire.
• Pinout Diagram
• Modchip Diagram
• FULL_CHIP_STOCK.bin
• Modchip Diagram, find the PA9(TX) and the PA10(RX) pins on your modchip, and do the following:
  • Connect GPIO14(TX) on your Raspberry Pi Zero W to the PA10(RX) pin on your modchip.
  • Connect GPIO15(RX) on your Raspberry Pi Zero W to the PA9(TX) pin on your modchip.

1. Solder a wire to each of the following pinouts on the Raspberry Pi Zero W:
   • 3.3V
   • Ground
   • GPIO 14 (UART TX)
   • GPIO 15 (UART RX)
2. Do the following to prepare the modchip:
   1. Lift pin 44 (also known as BOOT0).
   2. You will need a way to power the chip, so you need to find two 3.3v points. It can be on a MOSFET, but it will differ based on the revision of the modchip.
   3. Connect Ground on your Raspberry Pi Zero W to the Ground pin on your modchip.
   4. Check the Modchip Diagram, find the PA9(TX) and the PA10(RX) pins on your modchip, and do the following:
      • Connect GPIO14(TX) on your Raspberry Pi Zero W to the PA10(RX) pin on your modchip.
      • Connect GPIO15(RX) on your Raspberry Pi Zero W to the PA9(TX) pin on your modchip.
3. Boot your Raspberry Pi Zero W and do the following:
   1. In the terminal, type the following command, and press enter:
      

      sudo nano /boot/config.txt

   2. Add the following line to the end of the file:
      

      dtoverlay=pi3-miniuart-bt

   3. Press CTRL + X to save and exit the editor.
   4. In the terminal, type the following command, and press enter:
      

      sudo nano /boot/cmdline.txt

   5. Remove the following line from the file:
      

      console=serial0,115200

   6. Press CTRL + X to save and exit the editor.
   7. Restart your Raspberry Pi with this command
      

      sudo /sbin/reboot

   8. In the terminal, type the following commands, and press enter after each command:
      
      

      git clone https://github.com/Pheeeeenom/stm32flash.git
      cd stm32flash
      sudo make install

4. Now you will flash the modchip.
   Note: This will remove read protection, and the modchip will wipe itself (that is what we want).
   1. In the terminal, type the following command, and press enter:
      

      stm32flash -k /dev/serial0

   2. Now to flash Spacecraft-NX Version 0.2.0, type the following, and press enter:
      

      stm32flash -v -w ./FULL_CHIP_STOCK.bin /dev/serial0

5. Once you're done flashing your modchip, remove the wiring from the modchip, and restore the 3.3v pin on the modchip to its original position.

Please post pictures of your work here to further the identification of the different board revisions!


UPDATE: So it seems like stitching the spacecraft bootloader and firmware together from the repo causes unstable glitching behaviors. For now, consistent glitching behavior works with this bootload/firmware combo. This is the original file on the OLED variant chip which has 0.2.0 spacecraft. As for glitching, I'll figure it out, give me some time...unless someone else wants to hop in and reverse the differences.

For now, this at least solves the 0.1.0 HWFLY gen 3 issue. More to come.

UPDATE 2: This is only going to work on some HWFLY chips. Older ones use higher protection than the new revisions that seem to use the QFN FPGA.

UPDATE 3: This should fully work on OLED modchips with the QFN FPGA. https://github.com/Pheeeeenom/firmware

 

[doom95]

absolutely not. new distinguishable led patterns with documented description are a feature of 0.6.0

 

[fragged]

(Hopefully) Final version of 0.6.0 has been released:
https://github.com/hwfly-nx/firmware/releases/tag/0.6.0
There is an update to the bootloader, if you're going to flash it manually it's probably a good idea to update both the Bootloader & Firmware. More complete readme with instructions were also updated on the GitHub page.

 

[yee]

Followed this video by sthetix with the new 0.6.1 toolbox release to update it from 0.2.0.

Probably not going to bother flashing the bootloader since everything works fine and I'm too lazy to open the console again.

Glitches successfully after one purple flash instead of the several flashes I was getting before it would turn green.

 

[de9ed]

I tried updating 0.6.0-beta1 to 0.6.0-beta2 using included hwfly-toolbox.
It refused updating because of the same version number, so I put .force_update file in the sdcard and updated firmware.
But somehow update went wrong and after rebooting no light was coming from the modchip.
The firmware was broken and it always booted straight to OFW with no light.
I flashed 0.6.0-beta2 using ST-LINK and now it's working better than ever.
I think some additional safety measure can be useful.

I had the same issue, even on the latest firmware with toolbox

 

[lufeig]

updated fw from 0.5.0 to 0.6.1, updated toolbox as well.

it glitches almost instantaneously every time. one purple blink, green, done. two purple blinks, green, done.

thank you very much for the continuous efforts to keep it improving. well done!

 

[de9ed]

updated fw from 0.5.0 to 0.6.1, updated toolbox as well.

it glitches almost instantaneously every time. one purple blink, green, done. two purple blinks, green, done.

thank you very much for the continuous efforts to keep it improving. well done!

did you flash through debug port or through toolbox?

I think I have found the issue of why it cannot write new firmware to modchip (error was 0800300)

The steps were
1. flash with v6 beta 1 ( bootloader/sdloader/firmware) via debug port
2. flash with v6.1 (sdloader/firmware) via toolbox -> leads to firmware writing error -> modchip not turning on during boot and boots straight into ofw

 

[yee]

did you flash through debug port or through toolbox?

I think I have found the issue of why it cannot write new firmware to modchip (error was 0800300)

The steps were
1. flash with v6 beta 1 ( bootloader/sdloader/firmware) via debug port
2. flash with v6.1 (sdloader/firmware) via toolbox -> leads to firmware writing error -> modchip not turning on during boot and boots straight into ofw

I flashed 0.2.0 to 0.6.1 via toolbox with no issues. I'm guessing there is something wrong when flashing from 0.6.0 beta to 0.6.1. or perhaps debug to toolbox?

 

[lufeig]

did you flash through debug port or through toolbox?

I think I have found the issue of why it cannot write new firmware to modchip (error was 0800300)

The steps were
1. flash with v6 beta 1 ( bootloader/sdloader/firmware) via debug port
2. flash with v6.1 (sdloader/firmware) via toolbox -> leads to firmware writing error -> modchip not turning on during boot and boots straight into ofw

I flashed via toolbox.

I flashed sdloader first, even though I thought it was not necessary. Reboot, then I flashed firmware.

Reboot again and trained modchip.

Success!

PS. 0.5.0 was flashed via toolbox too. Previously it had 0.4.0 from Mena, flashed via debug port.

 

[Mena]

0.6.1 is beautifully written. No Chinese shortcuts during training. Very good work

 

[Dean_]

I tried 0.6.1 and after training, I had some trouble booting my switch.
I use my switch in my house and outdoors. But it seems that if I train in my house, it doesn't boot outdoors, vice versa.
When it doesn't boot light behaves like this (purple - slowly blinking -> yellow - blinking fast -> yellow - solid -> lights off)
It seems that some parameters change according to the environment. I'm really confused.
I rechecked wiring, but it seems solid.
I think some sort of flexibility may help this kind of problem..? Maybe too much accuracy during training can cause something like this..?? I'm just guessing.

 

[mocthulang]

i just bought it from alixpress. i have it installed and running perfectly. Does this modchip need to be upgraded to v 0.2 anymore?

 

[fragged]

This new 0.6.1 release is perfection, it trains very fast now & consistently finds the best glitch offset for my Switch.
In order to get all the features it's most likely best to flash both the bootload & firmware on PC by hooking your chip up to your computer by USB.

 

[Vladjaye]

This new 0.6.1 release is perfection, it trains very fast now & consistently finds the best glitch offset for my Switch.
In order to get all the features it's most likely best to flash both the bootload & firmware on PC by hooking your chip up to your computer by USB.View attachment 299965View attachment 299966

Can we flash everything using toolbox instead? I'm on 0.5 and wondering if I can do the new version using toolbox.

 

[fragged]

Can we flash everything using toolbox instead? I'm on 0.5 and wondering if I can do the new version using toolbox.

For the Firmware you can update that in toolbox, but you'd need to update the Bootloader manually for all the added functionality like the LED diagnostics I believe.

 

[Vladjaye]

For the Firmware you can update that in toolbox, but you'd need to update the Bootloader manually for all the added functionality like the LED diagnostics I believe.

So the 0.6.1 firmware would improve glitching regardless of bootloader? Bootloader is, from what it seems, for new led diagnostics only?

 

[doom95]

bootloader isn't strictly necessary but you will be asked to update it first in case there's support needed

 

[Vladjaye]

bootloader isn't strictly necessary but you will be asked to update it first in case there's support needed

I.e. the bootloader is for better understanding of what is wrong with chip\diagnostics only? The 0.6.1 alone should work fine?

 

[FR0ZN]

bootloader isn't strictly necessary but you will be asked to update it first in case there's support needed

What is the chance to support bootloader updates via the Toolbox?

 

[doom95]

none

 

[FR0ZN]

none

I see :/
What is the state of the current bootloader?
Is it robust as is, or do you think there will be more necessary updates in the near future?
Just asking, because I havn't installed my modchip yet.