search

Spacecraft-NX / firmware

GNU General Public License v3.0
255 stars 70 forks source link

HWFly Core Sleep #31

Closed james194zt closed 2 years ago

james194zt commented 2 years ago

Hi,

Trying to work out why my Switch is dying extremely quick, I am not convinced the HWFly core is going to sleep properly. Brand new switch Mariko (1 month old) drains about 6-8% an hour which is about the drain speed if the HWFly was fully on. Doesn't matter if it is a fresh install of Atmos running on Emunand OR the Sysnand with zero modifications.

Looking at the main.c I can see the sleep routine, and according to the SDK you are using the "lightest" of the 3 sleep modes which the GD32 support and I assume is the best we can use? I can see also the FPGA is being put to sleep by the routine as well as the LED, so I am assuming the FPGA and GD32 are going to sleep in code, but again who knows with the FPGA when we have no idea what is in there (that I am aware of anyway), and without debug who knows if the GD32 is.

I am just wondering if you know, is the V1 firmware on these modified in some way I can't find a dump anywhere so I assume nobody has managed to dump it, so maybe it is not going to sleep? I cannot see anything wrong with the install it is solidly soldered to the CPU, I have kapton tape underneath the chip to prevent shorts so don't think it is there.

Obviously we cannot debug (annoyingly), the only thing I can think of now is removing the GD32, replacing with a new blank GD32 and just flashing Spacecraft to it as the SWD flag will not be present so I can then get in to it and debug further.

Edit: Just to add, I have done some testing on the chip after reviewing the schematics, tests on ampage during operation are as follows:

As I was booting from EmuNAND I wanted to ensure the draw off the 3.3v line was what the board was pulling and not the EMMC, but the results for the drain are about the same regardless of what the chip is doing. To me it looks like the board is not going to sleep and as the draw is the same, I suspect both the GD32 and FPGA are both awake. I was hoping to see the drain drop once booted as I was kind of hoping at least the FPGA had gone to sleep!

Just wondering if you have any ideas on what else I can try?

balika011 commented 2 years ago

The HWFLY series modchips by Gateway run a heavily modified version of this firmware. You may try to flash it with an unmodified version.

james194zt commented 2 years ago

That is what I feared! I sadly don't have one of the chips you can pull up BOOT0 and then flash, just waiting on a couple of GD32 to arrive from China so can swap them over. Fingers crossed putting the real firmware on there not this modified version will sort it, I will updated once done so that we know either way.