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

 

[lufeig]

My firmware replicates their glitch.c. Your results should be identical

that is really strange, I am getting better glitching speeds with r021, just like MrGrinch.

I've just measured and compared their performances. I don't know why, but r021 glitches successfully much faster.

 

[MrGrinch]

hey very cool @lufeig ! Yeah I wonder what's different since Mena says it's the same. I'm still definitely keeping a close eye on his progress.

 

[Mena]

that is really strange, I am getting better glitching speeds with r021, just like MrGrinch.

I've just measured and compared their performances. I don't know why, but r021 glitches successfully much faster.

The only difference my firmware doesn't have is they look for voltage 1596. Mine has the stock spacecraft v2 value of 1496. I'll test the new one and report back

 

[lufeig]

The only difference my firmware doesn't have is they look for voltage 1596. Mine has the stock spacecraft v2 value of 1496. I'll test the new one and report back

one more detail:

training time for 0.2.0 China proper edition was around 10 minutes

training time for r021 was around 2 minutes

 

[Mena]

one more detail:

training time for 0.2.0 China proper edition was around 10 minutes

training time for r021 was around 2 minutes

hmmmmmmmm, i wonder if they use more offsets than spacecraft v2. This could just be my snobby attitude (since I prefer open source) but I prefer mine as of now because 1.) I know what's not my device. 2.) debugging is a breeze on my firmware since it allows you to see what's going on.

I will figure out the performance boost though.

 

[Mena]

one more detail:

training time for 0.2.0 China proper edition was around 10 minutes

training time for r021 was around 2 minutes

Also, outside of training...how's the difference with just booting in general?

 

[MrGrinch]

Again, data point of 1, but r021 performs very good for me. Consistent glitching, 2-5 binks then green, I don't think I've had a failure to glitch at all yet. Once it's past that no issues whatsoever.

I used to have the random failed glitch, sometimes after blinking for a long time, and rarely it would glitch green but end up at a black screen prior to the update.

Don't get me wrong, I was set on using your FW, I still look forward to it, but for me glitching performance is a larger daily advantage than debugging. I very much appreciate your work and hope I can have the best of both.

 

[lufeig]

I didn't measure the performance of your fw as precisely as I did with r021, but it was pretty like the stock one.

I counted 86 pulses, 12, 30... never small amounts in a row like 3, 2, 4, 2, like I got with r021.

 

[Mena]

Again, data point of 1, but r021 performs very good for me. Consistent glitching, 2-5 binks then green, I don't think I've had a failure to glitch at all yet. Once it's past that no issues whatsoever.

I used to have the random failed glitch, sometimes after blinking for a long time, and rarely it would glitch green but end up at a black screen prior to the update.

Don't get me wrong, I was set on using your FW, I still look forward to it, but for me glitching performance is a larger daily advantage than debugging. I very much appreciate your work and hope I can have the best of both.

And that's fine, your main priority is different than mine. The first person I sent my firmware to got 50 glitches trained in like 30s. The video of it is on the previous page. It's confusing to see exactly opposite results. He had worse results with their firmware and near-instant results with mine.

 

[fragged]

hmmmmmmmm, i wonder if they use more offsets than spacecraft v2. This could just be my snobby attitude (since I prefer open source) but I prefer mine as of now because 1.) I know what's not my device. 2.) debugging is a breeze on my firmware since it allows you to see what's going on.

I will figure out the performance boost though.

Would your Firmware run on an SX Lite? It would be nice to have a more up to date version, if it runs any better than stock SpaceCract-NX. Debugging would be cool to see as well.

 

[urherenow]

@Mena video appears broken to me, both on my computer and cellphone. is it only me?


@urherenow, out of curiosity, I noticed that you don't have any of the required materials to perform this kind of installation. have you ever did a service like this before? I know I should mind my own business first, but if this is your first time doing such small soldering, I would strongly suggest you to not try learning on the Switch. Trust me, it would probably be the most expensive lesson you ever had.

Lol... I have a military mind (retired) so I am a sucker for following rules/instructions (and I hadn't seen this exact video until now, but saw the same guy do an install of an HWFLY on an OLED... that's where I got my shopping list from). I've hard-modded an O3DS and N3DS, and replaced broken USB ports and capacitors on printer motherboards. Just a week or two ago, I replaced an analog stick on my Switch Pro controller. Nothing quite this small, but I have both a large magnifying glass with a light built in, and I have a cheap digital microscope. Also have a pretty decent soldering station (just wish I had purchased one with a hot air reflow thing and an electric solder sucker... because the manual spring operated ones are kind of a pain to use).

I think I'll be fine. I'd probably have finished already with the things I have (leftover wire from the 3DS hard-mods, for instance), if I didn't already have a launch-day switch with hekate to play with. Now, it's a matter of waiting to use the things I ordered for a false sense of not simply throwing my money away...

 

[lufeig]

Lol... I have a military mind (retired) so I am a sucker for following rules/instructions (and I hadn't seen this exact video until now, but saw the same guy do an install of an HWFLY on an OLED... that's where I got my shopping list from). I've hard-modded an O3DS and N3DS, and replaced broken USB ports and capacitors on printer motherboards. Just a week or two ago, I replaced an analog stick on my Switch Pro controller. Nothing quite this small, but I have both a large magnifying glass with a light built in, and I have a cheap digital microscope. Also have a pretty decent soldering station (just wish I had purchased one with a hot air reflow thing and an electric solder sucker... because the manual spring operated ones are kind of a pain to use).

I think I'll be fine. I'd probably have finished already with the things I have (leftover wire from the 3DS hard-mods, for instance), if I didn't already have a launch-day switch with hekate to play with already. Now, it's a matter of waiting to use the things I ordered for a false sense of not simply throwing my money away...

Great! I was worried that you could have zero experience and would probably brick the console! Clearly that’s not the case here, sorry!

Have fun hacking it!

 

[Mena]

Would your Firmware run on an SX Lite? It would be nice to have a more up to date version, if it runs any better than stock SpaceCract-NX. Debugging would be cool to see as well.

This would not work on an SX Lite because there isn't a magic value read on there before glitch attempts happen. I can remove that though. You have a debugger on standard spacecraft too

 

[tyiphius]

@Mena If I was to use an original SX Lite/Core on an OLED with the original spacecraft 0.2, will it still train itself to glitch?

 

[Mena]

@Mena If I was to use an original SX Lite/Core on an OLED with the original spacecraft 0.2, will it still train itself to glitch?

Yep

 

[leerz]

This would not work on an SX Lite because there isn't a magic value read on there before glitch attempts happen. I can remove that though. You have a debugger on standard spacecraft too

may I clarify

FULL_CHIP_STOCK is still for the core and lite hwflys that are NON QFN FPGA

and then this one for OLED https://github.com/Pheeeeenom/firmware


i have cores and lites atm and just waiting my RPI hdmi adapter and OTG to arrive then i would attempt to do the hwfly v3 core/lite so i could at least use them on an oled / and or the console they were designed to work on but with better fw (or at least when usb gets fixed)


i hope i didn't confuse

 

[heinrich_frei]

Hello, please help unbreak the OLED chip. After I flash the chip with the st-link v2 programmer, the chip glows purple. When connected to the console, it blinks green 1-2 times, then turns blue and the stock is loaded...

 

[NEOGEOKAI]

friends with this programmer I can flash a hwfly lite with spacecraft v2?

 

[Mena]

may I clarify

FULL_CHIP_STOCK is still for the core and lite hwflys that are NON QFN FPGA

and then this one for OLED https://github.com/Pheeeeenom/firmware


i have cores and lites atm and just waiting my RPI hdmi adapter and OTG to arrive then i would attempt to do the hwfly v3 core/lite so i could at least use them on an oled / and or the console they were designed to work on but with better fw (or at least when usb gets fixed)


i hope i didn't confuse

Everything I posted is for the QFN style chips. I haven’t tested QFN cores or lites if they exist

 

[JaRocker]

may I clarify

FULL_CHIP_STOCK is still for the core and lite hwflys that are NON QFN FPGA

and then this one for OLED https://github.com/Pheeeeenom/firmware


i have cores and lites atm and just waiting my RPI hdmi adapter and OTG to arrive then i would attempt to do the hwfly v3 core/lite so i could at least use them on an oled / and or the console they were designed to work on but with better fw (or at least when usb gets fixed)


i hope i didn't confuse

Why not just use putty to ssh into the pic that’s you don’t need to wait for hdmi