HWFLY chips will brick your OLED. Here is how to avoid it

First things first, I should start by saying that if you have an OLED-specific clone chip you're fine.

Anyways, all HWFLY Lite chips come with Spacecraft v1. For those that don't know, Spacecraft v1 sets certain pins to 5V that shouldn't be set to that on an OLED.

You can find more info in the readme of my application here: https://github.com/Pheeeeenom/payloadchecker

All this application does is check the payload that's currently written and checks it to verified hashes stored in the program.

Steps to follow are:

Boot hekate
Dump BOOT0
Check it on application

If you have a genuine modchip, update it to the latest Spacecraft v2 before you install it into an OLED.

The OLED-specific modchip also comes with broken USB debugging, if you want to fix this issue you will need to write this repaired firmware binary.
 
Also btw I took a look at the sdloader payload that does the misconfiguration, it seems to only run the code to route 5v wherever if it fails to load a payload off the sd card, so it's not as big of an issue as it initially seemed (still should probably avoid using it though).
View attachment 293228
(edit: setup_display leads to display_init, which contains the offending code)
i tried to run my oled for a while without sd card and only black screen appears... can it damage my device? and after restart and i put back a micro sd it work normal. also is same thing between "fails to load a payload" and run switch without an sd card?
 
Last edited by Tembokbesi,
i tried to run my oled for a while without sd card and only black screen appears... can it damage my device? and after restart and i put back a micro sd it work normal
As long as it has spacecraft-nx v0.2, you don't have to worry about black screen.
 
it's not your SD card, it's your consoles RAM
oh my bad, I had (mistakenly) misunderstood the memory to be in reference to my added external storage, rather than the console's internal RAM manufactured by micron.

would that mean that some models with the samsung-produced memory would be trainable and thus boot to the boot screen instead of the black screen?

thanks for the clarification!
 
oh my bad, I had (mistakenly) misunderstood the memory to be in reference to my added external storage, rather than the console's internal RAM manufactured by micron.

would that mean that some models with the samsung-produced memory would be trainable and thus boot to the boot screen instead of the black screen?

thanks for the clarification!
Exactly this
 
  • Like
Reactions: Afuri
Also btw I took a look at the sdloader payload that does the misconfiguration, it seems to only run the code to route 5v wherever if it fails to load a payload off the sd card, so it's not as big of an issue as it initially seemed (still should probably avoid using it though).
View attachment 293228
(edit: setup_display leads to display_init, which contains the offending code)
So will this problem linger after powering off if it were to be booted without the correct payload file on the SD card, if it was ever booted without that is it messed up afterwards? Or after a power off and then with the correct payload in place it wouldn't load the code that sends the 5V where it shouldn't?
 
Also btw I took a look at the sdloader payload that does the misconfiguration, it seems to only run the code to route 5v wherever if it fails to load a payload off the sd card, so it's not as big of an issue as it initially seemed (still should probably avoid using it though).
View attachment 293228
(edit: setup_display leads to display_init, which contains the offending code)

So if my switch is already correctly setup and working, as I never intend to actually switch it off, just rebooting to go from cfw to ofw and back, there should be no further risk so long as it correctly reads the payload on the very rare occasion it will need to? That'd be quite amazing if so
 
A lot of installers in my opinion boot once the install is done, before inserting an sd card to get that no sd message. i know quite a few like that. this explains one of the deaths my friend had
Not to mention user error and sd card failure, which btw happens more often than expected.
 
Also btw I took a look at the sdloader payload that does the misconfiguration, it seems to only run the code to route 5v wherever if it fails to load a payload off the sd card, so it's not as big of an issue as it initially seemed (still should probably avoid using it though).
View attachment 293228
(edit: setup_display leads to display_init, which contains the offending code)
God bless for this find. Should teach people to be extra careful and read the guides more carefully now :P

"Do things properly or you'll tase your board" :rofl2:
 
So will this problem linger after powering off if it were to be booted without the correct payload file on the SD card, if it was ever booted without that is it messed up afterwards? Or after a power off and then with the correct payload in place it wouldn't load the code that sends the 5V where it shouldn't?
If you were to boot without an sd card and it survives, then you do boot with an sd card, it wouldn't linger
So if my switch is already correctly setup and working, as I never intend to actually switch it off, just rebooting to go from cfw to ofw and back, there should be no further risk so long as it correctly reads the payload on the very rare occasion it will need to? That'd be quite amazing if so
yeah
 
  • Like
Reactions: Stryd
There is no regulator 3.3v just before the oled screen ??
if so there is no reason that the screen received 5v no .
 
For the arch flex chip, does anyone know (beyond an educated guess) which way the USB connector faces? It says "UP" on one side, but based on their behaviour before I wouldn't rule out the possibility that they have that on the wrong side. This is the chip I'm referring to:
PXL_20220111_194018405.MP.jpg
 
For the arch flex chip, does anyone know (beyond an educated guess) which way the USB connector faces? It says "UP" on one side, but based on their behaviour before I wouldn't rule out the possibility that they have that on the wrong side. This is the chip I'm referring to:View attachment 293291
Flip it over for the way you have it in that pic so it says up
 
For the arch flex chip, does anyone know (beyond an educated guess) which way the USB connector faces? It says "UP" on one side, but based on their behaviour before I wouldn't rule out the possibility that they have that on the wrong side. This is the chip I'm referring to:View attachment 293291
Yes, opposite from how you have it
 
  • Like
Reactions: Magnus Hydra
For the arch flex chip, does anyone know (beyond an educated guess) which way the USB connector faces? It says "UP" on one side, but based on their behaviour before I wouldn't rule out the possibility that they have that on the wrong side. This is the chip I'm referring to:View attachment 293291
Interesting you can see the GD32 chip code, on my HWFly core you cannot see that on my locked out HWFly as it has been laser etched off.
 

Site & Scene News

Popular threads in this forum