Worklog Modernized Wii spii

[pingu]

Howdy, this is where progress updates on my "re-envisioned" spii will go.

Currently planned features are
1. Omega trim
2. i2c controlled fuel gauge for OSD battery life
3. PWM fan support
(For 2 and 3 I am hoping to avoid using the PMS2 and rather use a custom homebrew app / lua menu using RVLoader similar to the Thundervolt)
4. Bu9095 AVE or RVL-DD depending on how the cards fall
5. Thundervolt-lite

Day 1:
I went ahead and modded my wii and prepared it for the nand relocation. Desoldering the nand was a breeze and I used a little bit of solder-paste to tack on the nand, filtering caps, and resistor. Afterwards I drag soldered the pins and was left with a fairly clean install. One tool that has been a life-saver for these flex installs is a pedicure dremel tool with an ultra fine grinding bit. This allows me to strip these vias easily (as I have tendon problems my hand isn't perfectly steady).

Luckily it booted first try without issue.

Day 2:
This was AVE relocation day. I happened to have a spare BU9055 AVE from another project, and transplanted it and its components onto the ave flex. Much of the same assembly-wise when compared to the nand. Unfortunately I could not get an image to post today, but will look with new eyes tomorrow. Here were the assembly pics I captured. (the wii does boot as wiimotes sync so this is purely related to the AVE-Relocation).

 

[Stitches]

Oof those vias....... for future projects I suggest getting a Fibreglass Pencil
They look like this v

It's an abrasive tool that uses clusters of aligned glass fibers to sand stuff off of metal without damaging the metal. It doesn't require much dexterity and doesn't damage the via, but it is a slower process. They're very cheap, a few dollars each.

 

[pingu]

Just picked some up. Although in the image some vias look to be "borked" (especially on the i2c Data/clock vias) this is actually just residual solder left inside them as I was probing the i2c lines a while back.
Though this will def help in getting the vias stripped consistently. Thanks for the reccomendation.

 

[pingu]

New day new me. I suspect the AVE that I used may have died (just a hunch as I recall the AVE having problems on the original wii it was on). In response I went ahead and transplanted a known working BU9055 AVE. I went ahead and built a second AVE-Flex using the components harvested from the first. However, despite my best efforts I still couldn't get video out. Is there anything I am potentially missing? Keen to hear a response.

 

[YveltalGriffin]

Well, first off I'd swap that Kynar for some 34AWG magnet wire:

Did you hot air the AVE onto the flex after tinning the GND pad? If the AVE's exposed pad isn't soldered to the FPC, the AVE will misbehave.

Also, some of the AVE legs on the left side don't look well-soldered. Nudge each one with tweezers under a magnifying glass or microscope to confirm they are soldered properly.

The GPU vias look good, but you should check for continuity between the original AVE pads on the motherboard and the AVE legs on the AVEflex. You can also check for shorts between all of the data lines.

 

[Stitches]

You have solder on the G pad, G is Green of RGB, not GND. There is a GND pad available right next to the Composite pad

 

[pingu]

Small update.
I managed to get video output!! Unfortunately the way I got there was a bit odd, I swapped in the Original Bu9955 AVE and it worked without a hitch after drag soldering and touching up some of the surface mounted resistors/caps. Unsure if the very first AVE was cooked, but this confirms the second one I was using to be faulty. I may keep this trim as is or carefully desolder the flex and assemble another flex for the BU9055 AVE. Unfortunately I am pretty busy with work until Wednesday.

If I recall YveltalGriffin has been doing research on the 480p bug fix on other AVE revisions, so perhaps with time we will have a "universal fix". Thanks for the tips!!

 

[RegDogg]

Love to see more people attempting the OMEGA trim, can't wait to see where this project goes!

 

[pingu]

I decided to take a break for now on the hardware side, and am beginning to focus on the software side of things. The following will be "spit-balling" and I cannot confirm that it is 100% accurate.

So, in picking a main microcontroller for my BMS board to work in conjunction with the thundervolt here is what comes to mind.

I was considering using the PIC18F26K42, this is the PIC controller found on the PMS2 and lite, using this controller comes with the main benefit that it has 2 dedicated I2C channels. This is useful because the main controller can act as a "bridge" where data is sent along the bus and the controller can do stuff in response. (I am assuming this is how the PMS does it in RVLoader). The main drawback of going this route, is while all of the software on the Wii side is complete, it leaves me to reverse engineer the custom I2c bootloader, which may not be in the scope of the project.

In contrast, from what I recall the Thundervolt uses the ATTiny controller purely as a mean to save all config settings into the non-volatile memory. I would imagine this means the Wii directly communicates will all the regulators independently along the i2c bus rather than directly speaking to the ATTiny.


Unfortunately, despite taking a university course in C/C++ programming I still struggle heavily in embedded programming, so if anyone had sources+tips on how to improve I am all ears (Although the best answer is always practice, I do want to complete this project without opening more side projects ha ha).

Here is the hope from the BMS board.
-PWM fan control
-I2C Fuel Gauge
-Lithium protection + USBC communications
-OSD temp

 

[KTW02]

wrt picking a microcontroller, take a look at the STM32 and RP2040 chips. A quick search on the ST Micro website's product finder gave the STM32G0B1 series that has both dual I2C and USB-C PD handling - and probably enough extra pins to serve as a GC+ substitute as well. The ATTiny1616 from Thundervolt is also fine, it has one I2C controller inside the chip but that controller has a bridge mode built in.

For microcontrollers that don't have built-in EEPROM for storing settings to non-volatile memory the way the ATTiny1616 does, most can read and write their own flash as a substitute, it just has a lower write limit of a few thousand cycles instead of hundreds of thousands of cycles.

Resources wise, I learned from porting random libraries and code samples on GitHub to the chips I have. There are a ton of ATTiny and ATMega bootloaders on GitHub that can be reworked into I2C bootloaders for Wii. I haven't worked with the newer AVRs, but all of the old ones follow the same read bytes via I2C/SPI/Serial -> compare them against what flash already has -> write the bytes to flash pattern, so it shouldn't be that hard.

 

[pingu]

Small update:

I managed to get the AVE relocation working with the BU9055 on the Wii! However, with the re-release of the DD I think it may be the better option for the "best" picture quality. Moreover, I am now planing on using a wii mini omega, and was wondering if it has been tested with the DD? Although the board seems near identical to a normal 4 layer wii better safe than sorry.

I also purchased an STM32G0B1 dev board, and nearly have the gc controller single wire protocol nearly mimicked. Still far from finished, but I do have basic ABXY button presses registering just fine!


I have started planning on how I would reverse engineer most of the PMS2s features, but had some questions

1. The PMS2 has a low resistance AON7407 Mosfet right at the B+ line my assumption is that this is how the PMS2 counteracts the PMS1s infamous issue of constantly drawing power even while powered off. However, if this mosfet isolates the rest of the PMS2 from the battery, then how can the main controller (the PIC) detect when a button is pressed or a switch is toggled based on what it was set as in RVLoader

2. We know that the PMS2 contains 4 regulators for the wii and a 5v boost converter for other peripherals, my question is are all the components running straight off of the batteries unregulated voltage? (the bq, PIC, fuel gauge etc.) And if it is regulated which regulator is it being powered from?

3. Although the PMS2 does support charge and play if I remember correctly the way it is implemented is the charger charges the baytteries, and the batteries power the system symotaniously, however the batteries still drain faster than the supply can charge them (maybe undervolting/HW2 can fix??). The question now is what is stopping us from doing a proper charge and play where the system is powered from the PD source and the batteries are charged in the process.