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]

No future updates that I can think of. The only way for the LED patterns to be somewhat logical and consistent required to get rid of the solid yellow in bootloader mode.
Updating bootloader requires first writing a specialized firmware image which allows access to the bootloader. This image is contained within BootloaderUpdater.exe. When the specialized image executes, we can overwrite the bootloader, and when that is done and the updated bootloader runs, we can re-write the standard firmware. This is a tricky process for which a reliable and quick mechanism should be used. The USB DFU method is proven and fast, so this is always preferred.

 

[FR0ZN]

No future updates that I can think of. The only way for the LED patterns to be somewhat logical and consistent required to get rid of the solid yellow in bootloader mode.
Updating bootloader requires first writing a specialized firmware image which allows access to the bootloader. This image is contained within BootloaderUpdater.exe. When the specialized image executes, we can overwrite the bootloader, and when that is done and the updated bootloader runs, we can re-write the standard firmware. This is a tricky process for which a reliable and quick mechanism should be used. The USB DFU method is proven and fast, so this is always preferred.

Thank you for the explaination!

Another question I had was about the first post.
What was the goal again here with all the pin lifting and applying voltage to it, etc. ?
I never saw this method again of updating the supported modchips

 

[doom95]

There seems to be a bunch of different modchip vendors out there. Of course the first batch of devices came from TX. These are 'flashable' and the open source spacecraft works fine on them. Then there's hwfly clones out there, where the 'sx core' and '6-wire oled' ones are categorized as "flashable" and the "hwfly lite" and oled version with quick-solder flex PCB are categorized as "unflashable". Both clone vendors use spacecraft code without any form of attribution. Also, both disable debug functionality. All of the modchips use the exact same GD32F350CB microcontroller, and so the question of intercompatiblity between firmwares and the open source alternative was raised.


Now when we look at whether or not these microcontrollers can be flashed in a meaningful way, the question really boils down to two things:
- do we have a replacement firmware?
- do we have an accessible way of writing a replacement firmware to the microcontroller?

The first requirement is an absolute necessity. Without compatible replacement, the only accomplishment of flashing something alternative is that you'll end up with a brick. The second question ties in with what this scene considers flashable, but in reality it's not that relevant; the microcontroller 'flashability' is never in question, provided you use an external programmer. If compatible firmware exists, we can force it on there.


To elaborate on this, we must first consider the different ways in which we can write firmware to these devices:
a) Using the userspace bootloader. This is a small firmware placed in front of the actual firmware. Both USB methods and hwfly-toolbox rely on this. We can even update this bootloader.
b) Using the embedded UART bootloader (the method Mena described)
c) Using an external programmer (st-link, gd-link, j-link, etc.) over SWD. Requires soldering.

Next we should consider the ways in which firmwares can be 'locked' during production:
1) Left unlocked, meaning firmware can even be read back. Unfortunately not encountered.
2) Read-out protection enabled
3) Read-out protection enabled + SWD/JTAG disabled


The 'flashable' chips use protection method 2) and sometimes include the userspace bootloader, while the 'unflashable' ones use protection method 3) and disable the userspace bootloader. Additionally, protection method 3) also disables flashing method b). The method Mena describes therefore helps on 'flashable' chips where the userspace bootloader was disabled. Regardless, flashing method c) is universally available and cannot be permanently disabled.

It was trivial to dump the firmware from modchips where the userspace bootloader was not disabled. Since then the Chinese vendor has also published firmware updates, making it even easier. This allowed us to make an open source compatible version that works well on these chips, which therefore received the label 'flashable'.

The other set of clone chips is considered poor: they use old 'spacecraft 0.1.0' and locked down their microcontrollers as well as they could. Userspace bootloader is made unusable too, and due to protection method 3) even Mena's method b) cannot work. That caused them to be labeled unflashable, but do realize that even if this worked, we still wouldn't have compatible firmware to write to them. Additionally, the point is entirely moot when we account for the fact that we can easily remove the read-out protection + SWD/JTAG block.

 

[urherenow]

so at some point, my clk wire came off. Now, I've really buggered it up. I've exposed the nearby ground plane and can't seem to get a wire stuck on there without shorting to ground now. I may have to try like hell to clean the solder off, and simply give up on the mod. The green UV-activated solder mask stuff hurts more than it helps, as either it sucks, or the UV light it came with sucks. What are the consequences of me trying to stick a wire a tad farther up, on the trace itself? If I can manage to get it on there, I have both a brownish and shiny green tape I can try holding the wire in place, in hopes of not ripping the trace...

 

[doom95]

I repaired one like that



Minor footnote, I only placed the botch wire, somebody else fucked up the trace.

 

[gokuz]

so at some point, my clk wire came off. Now, I've really buggered it up. I've exposed the nearby ground plane and can't seem to get a wire stuck on there without shorting to ground now. I may have to try like hell to clean the solder off, and simply give up on the mod. The green UV-activated solder mask stuff hurts more than it helps, as either it sucks, or the UV light it came with sucks. What are the consequences of me trying to stick a wire a tad farther up, on the trace itself? If I can manage to get it on there, I have both a brownish and shiny green tape I can try holding the wire in place, in hopes of not ripping the trace...

Seems like you're using the wrong tip. What soldering iron tip are you using?

You can scratch the line nearer to the cpu to get a "new" point of entry to check for shorts with GND and hope its not shorted, its super thin though, you need a good microscope to see it.

 

[cheesefinger]

0.6.1 working great.

Had some issues with timing flashing with usb. Failed a few times with "Spacecraft-NX DFU not found" after bootloader appeared to upload successfully.

Version in toolbox under update menu shows 0.6 rather than 0.6.1 using files from release_061.zip

 

[urherenow]

Seems like you're using the wrong tip. What soldering iron tip are you using?

You can scratch the line nearer to the cpu to get a "new" point of entry to check for shorts with GND and hope its not shorted, its super thin though, you need a good microscope to see it.

Yep, I took care of the short. I brought home a needle probe adapter for my fluke at work to get at the point. The sucker is sharp because I barely touched the trace with it and exposed it. Checked it there as well and got like .668 on diode, using that adapter. I'm now just covering that whole mess with mask and leaving it alone for yet another day. Then... I'm going to get the positioning down and routed around the screw hole and wayyyyy far away from that area, holding it in multiple spots with high temp pcb masking tape... and see if I can't get solder to stick to that trace and build it up onto the wire (which will be parallel to the trace in that one spot). IF I can manage a good joint and reading, I'll use more mask over the wire and trace, AND another piece of the tape on top of that. It won't be pretty, but I'm thinking it should work.

 

[PamanX]

Hi, Do you think I can use the oled v4 flex cable instead of the linear flex that comes with this chip, which is not recommended? The other points would be soldered with cable so as not to use the U ribbon cable

 

[Donnie-Burger]

SX Lite hwfly cant update to 0.6x. Get dfu found and stuck on bootloader. I get a white light on glitch. Is this a defective chip?

 

[FR0ZN]

SX Lite can be updated - HWFLY Lite however can't

 

[Donnie-Burger]

SX Lite can be updated - HWFLY Lite however can't

Thank You. I figured. I'm pretty sure this is a defective chip though. White light on glitch. Dont have a spare chip or spare lite to be 100% though.

 

[gamer0]

This is the official site of the QFN FPGA chip. chipnx. com

 

[Donnie-Burger]

This is the official site of the QFN FPGA chip. chipnx. com

What markings on chip signify package?

 

[gamer0]

this

 

[Donnie-Burger]

this

Do we have both versions to compare?

Figured it out by re touching up solder points. HWFLY Lite is good.

 

[fragged]

Hi, Do you think I can use the oled v4 flex cable instead of the linear flex that comes with this chip, which is not recommended? The other points would be soldered with cable so as not to use the U ribbon cable

Do not buy from Ming! He screwed over so many people selling "V3" HWFLY Lite's that had SpaceCraft-NX 0.1.0 on them and were actually V1's that can't be updated, and was telling everyone that they are perfectly safe to install into an OLED, even after all this info about the outdated chips came out & what they can do to an OLED.
I'm still waiting on a $170 refund from him on an order from Dec 7th, which I had to pay $18 just to ship that chip back to him...

 

[xdMatthewbx]

This is the official site of the QFN FPGA chip. chipnx. com

Sorry, but can you provide verification of this? I'm a little bit sceptical given the fact that the site contains images for the OLED and Core variants, but no image for the Lite (which would make sense for someone making a fake, given nobody has seen a lite variant of the flashable chip right now).

 

[doom95]

they don't make the lite clones, so that makes sense

 

[xdMatthewbx]

they don't make the lite clones, so that makes sense

Makes sense if it's a fake. The site lists a lite chip, just no image for it.