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]

led is rgb. yellow is red+green combined. if powered on from usb the led is set to static yellow indicating debug console is available. all good.

 

[FR0ZN]

So I should try the flash.bat?

 

[doom95]

sure

 

[FR0ZN]

Device Manager just says DFU and can't find any drivers.

 

[doom95]

find the device in device manager, update driver and use the serial/com port one. its a windows built-in one.

 

[FR0ZN]

find the device in device manager, update driver and use the serial/com port one. its a windows built-in one.

Do you know which driver I need?
Windows is not able to find one itself.

Maybe because I'm still on Win 7?

 

[doom95]

should say USB Serial Port

 

[FR0ZN]

Nope
Whenever I connect it, it just shows DFU as a new unknown device - the other two COM devices never change:

 

[FR0ZN]

Nope
Whenever I connect it, it just shows DFU as a new unknown device - the other two COM devices never change:

View attachment 299123

Does the Vendor ID and PID help?

 

[doom95]

yes, update the driver for the DFU entry.
not sure if it's a win7 thing. shouldn't be.

 

[FR0ZN]

yes, update the driver for the DFU entry.
not sure if it's a win7 thing. shouldn't be.

Windows can't find any drivers on it's own.
Do you which I need?

Vid: 600D and Pid: c0de - as in Good Code?
This seems to be something custom, I can't find any driver online when I look for the VID/PID - that's probably also why Windows can't find them.

 

[doom95]

You can try any USB CDC one, i.e. https://www.mediafire.com/file/9rqxi2zklxu9v1j/android_cdc_driver.zip/file

Or either of the 32/64bit ones here:
https://www.zebra.com/us/en/support-downloads/software/drivers/usb-cdc-driver.html

 

[FR0ZN]

None of these work - probably because non the drivers have the Vid: 600D and Pid: c0de in their inf files.
So Windows will never find it as a compatible driver.

 

[doom95]

well you can modify the inf with those pid/vid, but ultimately I'd say going to win 10 or 11 might be the wiser course of action

 

[FR0ZN]

well you can modify the inf with those pid/vid, but ultimately I'd say going to win 10 or 11 might be the wiser course of action

I don't think Windows 10 will change anything here, because Vid: 600D and Pid: c0de is not a valid vendor ID and probably not a valid product ID).
Someone (probably the seller) modified the software on the chip to report itself as Vid: 600D and Pid: c0de - as in "Good Code".

So I need someone who can tell me which driver is installed on his PC for this device and modify it myself to include Vid: 600D and Pid: c0de

 

[doom95]

no, win10 has built-in support for CDC
see https://docs.microsoft.com/en-us/wi...b-driver-installation-based-on-compatible-ids

 

[FR0ZN]

I modified the Android CDC driver and installed it - the modchip reported itself as "
MediaTek USB VCOM (Android)(COM5)" in the device manager afterwards:

So I ran flash.bat and it got this far:

After it said Timed out, Windows recognized a new DFU device with the following VID / PID: Vid_BAAD Pid_C0DE

So I modified the driver again, disconnected and reconnected the USB cable again - installed the modified drivers again and reran the flash.bat:

Looks good to me no?

 

[doom95]

yep. it uses a different pair of pid/vid for bootloader mode where we can rewrite firmware, and bootloader mode where even the bootloader can be overwritten.
nice work

 

[FR0ZN]

yep. it uses a different pair of pid/vid for bootloader mode where we can rewrite firmware, and bootloader mode where even the bootloader can be overwritten.
nice work

Thank you for your help!

If anyone runs into the same issues, this is the driver that I modified and used to update the modchip:
https://anonfiles.com/x4F583Jex0/android_cdc_driver-modified_zip

 

[urherenow]

If anyone runs into the same issues, this is the driver that I modified and used to update the modchip:
https://anonfiles.com/x4F583Jex0/android_cdc_driver-modified_zip

I grabbed it just in case. I couldn't do anything on Win 10, even though it DID show up as a COM port, but I'm going to wait until I install it to see if I can use the new toolbox thing first. This driver will be my second to last resort (last resort would be waiting for my GDLink-OB to arrive in the mail).