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

 

[LeGenD_ArMoUR_]

Ok i fix it! not working

Look at your 103 resistor it's been knocked off fix that and try again

 

[LeGenD_ArMoUR_]

I have a hwfly here, but those two circled burned themselves off the board, anyone know what they are? If I can fix those ill be able to give this a go myself as this is a trash chip now..

 

[Sandmann]

"You moved 103 resistor"

No, is a new revision:
https://psxtools.de/forum/index.php...xecuter-klone-hwfly/&postID=871766#post871766

 

[iolo57]

I have a hwfly here, but those two circled burned themselves off the board, anyone know what they are? If I can fix those ill be able to give this a go myself as this is a trash chip now..

CSD13381F4

CSD23381F4

 

[LeGenD_ArMoUR_]

CSD13381F4

CSD23381F4

Thanks for that just ordered some

 

[iolo57]

Thanks for that just ordered some

if you are interested here are the complete pcb files of a sx core / hwfly:
https://mega.nz/file/QSokxQQb#hreeUG-Vd5kHEJwoRGWfvOccOg5IixXO-VyqpkpRA_w

 

[urherenow]

So... idiot with the hardware stuff here. I'm wondering about the 2 3.3v pins on the Pi. Are those for input, or output? Just wondering why it says to find 2 3.3v points. But the rest sounds like you can connect just 1 wire to one of the Pi 3.3v pins, and the other end to pin 44, after it is lifted off of the board. Why TWO 3.3v points? So confused...

I don't even know what I'm getting yet, because there was no picture of it. I just know I ordered an OLED kit, and the supplier said they confirmed from the factory, that it was flashed with v0.2.0. So... I may not have to worry about this thread anyway (assuming I'm lucky and it plays nice with both my sd card and emmc). We shall see...

 

[Mena]

There seems to be a mixed bag of this shit too.

“```High level protection: when set OB_SPC byte value to 0xCC, high level protection performed. When this level is programmed in debug mode, boot from SRAM or boot from boot loader mode is disabled. The main flash block is accessible by all operations from user code. The option byte cannot be erased, and the OB_SPC byte and its complement value cannot be reprogrammed. So, if protection level high has been configured, it cannot move back to low protection level or no protection level.```”

My core had the QFN based FPGA. Maybe my MCU did not have the high security bit set. Apparently there’s a way to bypass too

 

[innercy]

this discussion is out of my league

 

[Zeeko]

Mena thank you very much for all your hard work. Has anyone done this successfully with St link programmer. I would kindly like to know how to use it with the ST-Link USB programmer. A noob guide would be kindly appreciated and what programme e.g. Linux, ubuntu etc. Thank you.

 

[mvmiranda]

if you are interested here are the complete pcb files of a sx core / hwfly:
https://mega.nz/file/QSokxQQb#hreeUG-Vd5kHEJwoRGWfvOccOg5IixXO-VyqpkpRA_w

Can we make a clone chip and program it then?

 

[iolo57]

Can we make a clone chip and program it then?

Blank chip already exists but you can also have it done on a site like pcbway. we can already program the mcu but not yet the fpga.
https://media.discordapp.net/attach...hnu832xfIR7RIAAkzlicuEZMTniowgoXpL2uHNC_T.jpg

 

[iolo57]

Blank chip already exists but you can also have it done on a site like pcbway.com . we can already program the mcu but not yet the fpga.
https://media.discordapp.net/attach...hnu832xfIR7RIAAkzlicuEZMTniowgoXpL2uHNC_T.jpg

 

[mvmiranda]

Blank chip already exists but you can also have it done on a site like pcbway. we can already program the mcu but not yet the fpga.
https://media.discordapp.net/attach...hnu832xfIR7RIAAkzlicuEZMTniowgoXpL2uHNC_T.jpg

Is it locked or so?

 

[iolo57]

Is it locked or so?

no but the chip comes blank (mcu and fpga)

 

[shadow256]

@Mena : I've compiled the program for Windows witch flash the modchip but I don't know what to indicate in place of "/dev/serial0" in the commands. Do you know where I should search to find this value on Windows?

 

[shadow256]

@Mena : I've compiled the program for Windows witch flash the modchip but I don't know what to indicate in place of "/dev/serial0" in the commands. Do you know where I should search to find this value on Windows (I use a ST-link programer)?

 

[mvmiranda]

...

In the terminal, type the following command, and press enter:

sudo nano /boot/cmdline.txt

Remove the following line from the file:

console=serial0,115200

...

@Mena, I got a bit confused here.
Mine has only one line and you mention to delete the line but only this much matches what you posted:

Should I remove the entire LINE or just this first "console=serial10,115200"?
Thx!

 

[james194zt2]

@Mena what response should we get LED light wise when we plug it in? I get a red light on the LED then nothing, on the console I get

Interface serial_posix: 57600 8E1
Failed to init device, timeout.


wiring checks out no shorts etc... Pin 44 is lifted and 3.3 applied as well, Just going to double check my RX and TX are to the correct pins again just in case

 

[Mena]

There seems to be a mixed bag of this shit too.

“```High level protection: when set OB_SPC byte value to 0xCC, high level protection performed. When this level is programmed in debug mode, boot from SRAM or boot from boot loader mode is disabled. The main flash block is accessible by all operations from user code. The option byte cannot be erased, and the OB_SPC byte and its complement value cannot be reprogrammed. So, if protection level high has been configured, it cannot move back to low protection level or no protection level.```”

My core had the QFN based FPGA. Maybe my MCU did not have the high security bit set. Apparently there’s a way to bypass too

@james194zt2 I'm starting to think the newer batch of clones are the ones with less protection. @sean222 is sending me his lite for me to work on