Worklog Some PS2 Project

[mknrls]

hat to you. that is some amazing progress!

 

[StonedEdge]

Wow! It’s commendable that you were able to get this working let alone in the short time frame you did. I’m excited for what’s to come! Do you plan on building a fully integrated portable/your own spin on the PS2 slim?

I hope you also go back to your CM4 portable at some point too, whenever those are back in stock. Would love to see more of those out there - I’m sure you had big plans for the MCAD/PCB carrier board. But that is no where near the complexity of this project.

Spicy!

 

[Stitches]

Update time!

3 weeks have passed since my last update and in this time, I went through engineering hell and back.

But the hard work was worth it, I am excited to announce that the first prototype of my custom PS2 mainboard finally boots! I literally managed to get it working 2h ago and the system was stable during a quick Okami session. Here it is:
View attachment 26347View attachment 26348
(BTW: my temporary “cooling solution” managed to keep the EE pretty cool, don’t make fun of it! Also please ignore all the flux residue on the board, I call it "battle scars" from 2 weeks of troubleshooting...)
View attachment 26349View attachment 26350

I assembled the board 2 weeks ago with components from my last 79004 mainboard. The reballing process was very smooth, maybe I can give some insight on how the process looked:

Reballing Process

The first step was to desolder the EE, GS, Mechacon, DSP, Ethernet PHY and System clock PLL and to clean them using solder wick. I did the desoldering using my IR preheater and hot air tool, that makes it a lot easier to melt the original lead-free solder. The temperature on the preheater was set to ~360°C and the hot air to 320°C, 90% airflow, that gave pe pretty good results without cooking the chips too much.
View attachment 26351View attachment 26352
I can recommend to clean the pads of the BGAs very thoroughly using solder wick, that way the solder balls stay in place much nicer later on. It is also important to apply as little force as possible on the pads while cleaning. When that was done, I cleaned the flux residue on the 3 BGAs using 99% isopropanol.

With that preparation done, I continued to mask the unused holes in the stencil. I’m using a 0,55mm universal stencil with 1mm pitch. In case anyone has the same reballing fixation, I applied some kapton tape in 2 diagonal corners to prevent the lid from moving around too much, as the sloppy tolerances made the alignment really tricky.
View attachment 26353View attachment 26354
The next step was to apply a thin layer of tacky flux on all pads of the BGA, I used my finger to spread it evenly. The BGA was mounted in the fixation and the stencil was aligned very carefully. The vertical alignment is also VERY important! If the distance between BGA and stencil is too big, the solder balls will not be aligned. If the distance is too small, the balls will not stay inside the holes and when they pop out, they will contaminate the top of the stencil and the other solder balls with flux. That causes the balls to get stuck in the stencil when lifting it off the BGA (which is a big pain, as those balls will have to be placed manually). Always clean the stencil after reballing!

When all balls are in place, I use the preheater and hot air again to melt them. I had good experiences with putting the BGA on an unused stencil and having it over the preheater (set to ~360°C). I usually set the hot air to 320°C, 10% airflow to not blow the balls away while heating. That way, I can slowly hover over all pads until all balls are soldered.
View attachment 26355View attachment 26356
That’s the reballing procedure I followed for the EE, GS and Mechacon. One thing that really annoyed me was the fact that I only have one stencil. That means I have to mask the holes 3 times to reball the 3 chips. Having 3 stencils would save a lot of time, so I ordered new ones from aliexpress.

Placement

Next was the component placement. There is this fancy KiCad plugin called “Interactive HTML BOM” which exports the BOM and a visual guidance where to place the components on the board. Man, I love that thing and I whish Altium had something similar, it makes the component placement SO MUCH easier.

The first side to be populated was the bottom layer. I ordered a solder paste stencil together with the PCBs, so that was very straight forward. When all components on the bottom were placed, I put the board on the preheater again and soldered everything using hot air on a first reflow run.
After that, I put copper tape on the ffc sockets, the mezzanine connectors and the LDOs to prevent them from falling off during the second (top side) reflow.

Then I turned the board around and populated everything on top, except the 3 BGAs. When the top side was done, I put the board back on the preheater at 360°C. I applied a thin layer of flux on all BGA pads of the PCB and placed the BGAs on the PCB. At work, our PCBA assembly house usually does it the other way around – they dip the BGA balls in a low viscosity flux before placing them.

The alignment of the BGAs was very easy, because I have the exact size of the package outlined on the silkscreen – I would highly recommend that for hand-assembly.
Then it was just a matter of heating the board up to solder all components. The BGAs are usually a bit more difficult to observe without the right equipment, so I always give them the -tiniest- push and when they “float” back into position, the connections are good.
After slowly cooling down the CBA, I measured the resistances on all supply rails and they seemed OK.

View attachment 26357View attachment 26358
View attachment 26359

Testing

That was the point where the fun started…

When powering the mainboard on for the first time, the red power LED turned on – so far so good. When pressing the reset button, the LED turned green, but the current consumption stayed at around 200mA. The board was completely dead, there was no video, no audio and not even bus activity on the EE-GS bus and the EE-DSP bus.

I compared most signals to a working board and saw that the EE was not even initializing when powering the board (with the red LED on).

On the good board, even before pushing the reset button, most signals between the EE, GS, DSP were initialized HIGH, the clocks for the EE, GS and ethernet PHY were present. The EE was outputting clocks for the DSP and for the GS. When pressing the reset button the console boots normally with bus activity everywhere.

On my board, a lot of the connections between the EE, GS and DSP were floating at around 0,3-0,6V. The respective clock signals for the EE, GS and ethernet PHY were present, so the system clock PLL was working. The EE did not output clock signals to the GS and the DSP. The CE and OE for the DSP/BIOS were floating at 0,3V, on the good board they were HIGH.
The GS did output a clock to the EE and the Mechacon also seemed to do its job – it tried to boot the system, tried to enable the supply rails and it was outputting a clock to the EE when pressing the reset button. What did not work, though, was turning the system off – it looked like the Mechacon was waiting for something.

These observations made me rule out the GS, clock PLL and Mechacon in my attempt to find the fault. The remaining suspects were the EE (highly sus), DSP and ethernet PHY. What made me rule out the DSP and ethernet PHY in the end was the fact that they were also doing nothing on the working mainboard, at least before pressing the power button. Everything that was supposed to come from the EE was missing on my mainboard and that led me to suspect three likely causes for my issues: wrong connections in my design, bad solder joints on the EE and a broken EE.

I decided to first compare my design to the original mainboard again to find the potential wiring issue. The second and more dangerous step was to replace the EE to solve the remaining 2 issues I suspected. I was a bit hesitant with replacing the EE, as there is a high risk of destroying the board in the process (and wasting a good chip while fixing nothing), so I continued with cross-checking the connectivity of the design. I had my design and the original mainboard next to each other and spent 2 weeks comparing every connection by hand using a multimeter. The conclusion from that was that there is no difference between the 2 boards that would prevent mine from booting. Dead end.
View attachment 26360

That forced me to replace the EE today. As I don’t have any more 79004 mainboards in stock, I had to salvage the new EE from a 90004 mainboard.

Side note: I decided to stop looking for 79004 mainboards, they are just impossible to find. Not a single reasonably priced one was available in the last 6 months and since the PS2 Ultra Slim was released, there are a lot of people actively searching for those mainboards. Importing 79001 consoles is not an option either, as the shipping is usually >50 bucks. Thankfully, nobody wants the 90004 and they are on sale for ~15 bucks quite regularly. I currently have 4 of them in stock and order new ones as soon as they are available.

After replacing the EE, my mainboard finally boots into FMCB. I still don't know whether the issue was a broken EE or bad solder joints, but knowing that I soldered the board at 2AM, I would expect the latter to be the case.
What is currently tested: memory cards, gamepads, loading games from USB. Muting the audio when resetting the console is not working currently, because it's not implemented in my video/audio relocation. You hear it when turning off the console while running a game – there is a loud buzzing sound for 1-2 seconds before the console turns off.
I also noticed something else: the new EE from my spare 90004 mainboard is different from most other EEs I’ve seen. That donor console also had a MUCH smaller cooling solution. During testing, I noticed that this new EE (subjectively) runs cooler that the one found on my reference mainboard. My custom mainboard also draws ~200mA less (currently at [email protected],5V without anything plugged in) than my modified original mainboard.
Speaking of current consumption – I’m very happy with that. With a BlueRetro, a memory card and a USB stick plugged in, the console consumes ~8,9W.

Testing is still ongoing, of course!

View attachment 26361

Front IO Breakout

Here is a closer look on my front IO breakout board. It works great so far. I still have to design a custom fixture for the memory card locking mechanism.
View attachment 26362View attachment 26363

I’m tired and dizzy from all the flux fumes today, so I will end it there (Note to self: buy a proper fume extractor one day). Please excuse any mistakes I made in the update, I'm completely done for now. There will be another update on how I’m planning to continue soon, but this week I will probably take some time off from the PS2 project. I will also have to clean all evidence of 2 weeks of troubleshooting off my lab bench before continuing with anything…

View attachment 26364

Holy fuck man............ WIZARD!

N64 and PS2 down, just the Wii left to go! THEY SHALL ALL BE SMALL!

 

[Y2K]

Should rename this thread from "Some PS2 Project" to "*THE* PS2 Project", as that's currently the state of things!

Incredible work, can't wait to see what comes of this. Next thing to look at would be to see how doable mounting the EE on the other side of the board would be. That would significantly shrink the size of the board down. Might need a proper BGA soldering setup for that though :/

 

[cfc_12]

OMG man,

Now, that's an insanity of amazingness!

You're like on a Gman level!

 

[Tschicki]

Thanks!

I said that I would take this week off, but I couldn't resist...

I've played some games on the board now for a couple of hours and.... man, I hate USB loading; loading times are terribly slow, FMVs are hardly watchable and compatability is trash. And don't get me started on all the fragmentation errors when having more than 3 games on my USB... I think the universe is trying to tell me to finally design an ffc adapter for my smb server! That will make testing easier and more reliable, I hope.

The hardware on the other hand is very stable so far. Apart from incompatibe games, there was not a single crash during gameplay and the longest uninterrupted playing session I had was ~3h(Okami). I also managed to create an improved temporary cooling solution out of parts from my junk bin, a sad looking 20mm fan from another project and a tiny heatsink. It works surprisingly well, keeping the EE hand-warm after 2-3h of playing.

The flux residue was bothering me, so I cleaned it off nicely. Now I can give you some close-ups without feeling ashamed of that filthy prototype.

Now that I have a working design, I took a step back to sort out my priorities. There are still a couple of things to design/test, before I'm fully satisfied with my current testing setup:

• Ethernet (SMB game loading)
  • I have to design an adapter to connect my SMB server via ffc
• my BIOS fix by tapping off the DSP CE
  • I will need to design a new BIOS module with the S29JL064J55TFI000 and the inverter
• Mister M suggested to try undervolting the EE to reduce the power consumption, I would like to do some feasibility on that.
  • My current 1V25 regulator does not go below 1.2V, so my plan is to design a new regulator board (also to get rid of that big chungus of a regulator board)

Incredible work, can't wait to see what comes of this. Next thing to look at would be to see how doable mounting the EE on the other side of the board would be. That would significantly shrink the size of the board down. Might need a proper BGA soldering setup for that though :/

I'm also thinking about that, maybe that's something to test in an upcoming revision. It will not be possible without moving the GS too, as the pinouts are very much optimized for the current placement. That would mean EE and GS on one side; DSP, Mechacon, Ethernet PHY and clock PLL on the other side. It would also be an option to split the mainboard in 2 modules and stack them, in case flipping the chips would require an HDI design (always thinking about keeping the cost down). The benefit of that would be that it requires no fancy soldering setup.

The plan for the future is to work on a handheld console (when the mainboard design is ready) and from now on I will keep that system in the back of my head when implementing new things.
The first thing where this applies is the regulator board and I think it makes sense to already design it with a future portable in mind. In order to do that though, I have to know roughly how the system architecture will look like.
That's why I started thinking about the system architecture and power delivery concept of the portable this week. There will be an update on that soonish...

As you all know, engineering is always about finding the most ideal compromise. I'm currently compiling a list of benefits and drawbacks of different cell configurations for the battery. My two options are 1S2P and 2S1P. I know it might not sound like a big deal, but a 1S or a 2S battery will have a big impact on all aspects of the power management design.
I would also be interested in hearing opinions and experiences of other people here! Suggestions would be much appreciated!

I also started to think about possible form factors for the portable. Hmmm....
My favorites so far are the PS Vita (might be tight though) and the Switch, but starting from scratch with a custom form factor sounds exciting too! Will think about it...

 

[Wesk]

 

[Fly_5]

.
I'm really impressed it's an amazing project

 

[Tschicki]

Small update!

Ethernet
SMB game loading is fully working, no modifications required! I figured it would be easier and faster to solder the ffc adapter for my mini router by hand, it's just 8 wires. Not my finest soldering job, but it will do just fine for testing. Below is an image of the board. The nice thing about it is that the ffc also includes 5V and GND -> all I need to get the router running is really just that 8 pin ffc. That was actually the last feature to test on the mainboard itself.
The games that were tested so far via SMB include Rayman 3, Okami, NFS MW, Shadow of the Colossus, Ratchet&Clank and GTA San Andreas. There was not a single crash so far and especially GTA was running for a couple of hours - time really flies once you spawn a hydra jet...

BTW the mini router I'm using is from Aliexpress, just search for "3G mini router". I saw it in one of Mister M's posts and ordered a couple for testing - at 7 bucks per piece. It's not the most reliable router - I ordered 3 and at this point only one still works - but the power consumption is outstanding at ~1W + it is very small.

BIOS Module with CE-fix
The module was designed and ordered. The 74LVC1G04 inverter is now included in the module, it will require one bodge wire on the mainboard between /XHCE (DSP pin 169) and the module's CE pin.

Regulator Board
In order to have a rough guideline when designing the regulator board, I came up with a draft power supply concept. It is by far not final, but it should provide good input when searching for ICs and doing the schematics. Ideas for improvements would be very welcome!

The current plan:
I will work on a prototype of the red blocks in the upcoming weeks. Then I can also test undervolting the EE, as suggested by Mister M.
When that is working, I will move on to the orange blocks (battery management). From time to time I will also work on the purple blocks, as they are a challenge on their own and I expect the implementation to be very time consuming.
I'm doing the design in smaller chunks on purpose, because it will be easier to test and troubleshoot a modular system + it helps to keep me motivated when I can achieve a bunch of smaller successes by getting the subcircuits working. The size of the system is also not one of my concerns right now, miniaturization will start when the circuits work as expected.

SysCon
While thinking about the power management & architecture, I quickly realized that I will need some sort of system management controller to handle everything except running the games. That includes USB C PD, battery management & SOC, power on & off & sequencing, fault handling, gamepad inputs, audio & video output settings. The preliminary name for it is SysCon, in memory of the PS2 SysCon that was removed after the 39k revision. I've written dowen some tasks and interfaces that I would like the SysCon to handle. There is no decision for a mcu yet, but right now I'm thinking about using a mcu in the STM32L4 series, because I already have some experience with them.
Not all tasks will be implemented right away, the first things will probably be power on & power off + maybe looking into the PS2 gamepad interface.

 

[thedrew]

looking good! Really love this worklog.

If I can offer a suggestion, I would take a look at MX4SIO instead of SMB loading. Not sure if it works with 9K PS2 models, but don't see why it wouldn't. It will save you space and power since you can run the games off a Micro SD card wired directly to the memory card 2 port. I have tested 30+ games without issue with only 1 game having FMV stutters, which I believe was actually just an OPL compatibility problem. Those games gave me stutters with USB loading but not with MX4SIO. The loading speeds are faster than the slow usb speed. Wesk made a post about getting it working here if you are interested:

https://bitbuilt.net/forums/index.p...-ps2-portable-for-sd-loading-79k-models.4977/

 

[Tschicki]

looking good! Really love this worklog.

If I can offer a suggestion, I would take a look at MX4SIO instead of SMB loading. Not sure if it works with 9K PS2 models, but don't see why it wouldn't. It will save you space and power since you can run the games off a Micro SD card wired directly to the memory card 2 port. I have tested 30+ games without issue with only 1 game having FMV stutters, which I believe was actually just an OPL compatibility problem. Those games gave me stutters with USB loading but not with MX4SIO. The loading speeds are faster than the slow usb speed. Wesk made a post about getting it working here if you are interested:

https://bitbuilt.net/forums/index.p...-ps2-portable-for-sd-loading-79k-models.4977/

That's a good point, thanks! The MX4SIO was completely off my radar for game compatibility reasons, but it looks like they improved it recently!
I ordered the MX4SIO + a samsung SD card and will try to do some tests on the weekend.

There is only one concern I have when it comes to implementing it in my portable. I have a strict requirement for having a full size memory card slot for savegames, because I want an easy way to transfer saves between my fat 39k and the portable. Just to replicate a portion of that retro feeling when you bring your memory card to a friend's place to finish a really hard level on a game.
I'm a real noob when it comes to the software side on the PS2, but as far as I understand, the MX4SIO must be plugged into port 2 and the FMCB card into port 1 of the console. Games are then saved to a VMC on the FMCB memory card? Can you then plug that FMCB memory card into a FHDB softmodded console to continue playing? Maybe I should do some testing on that, because the savegame topic is really important to me.
In case it doesn't work I could think about some ways to develop around this:

• I noticed that unplugging the FMCB memory card is fine after launching a game. Maybe it would be possible to switch from FMCB to a regular memory card for saving games using some logic (e.g. small bus switch) to drive the CE of both cards accordingly. I would just have to figure out how to detect when the PS2 is launching a game.
• Looking into the Multitap would be an option, but I don't really like that idea as it sounds like a lot of additional work for little benefit
• It might sound stupid, but maybe it would be possible to replace the original OSDSYS in the BIOS with the hacked version from FMCB. Or modify the stock ELF loader to load OPL directly from MC or USB during booting. Then I could get rid of the FMCB memory card altogether. In the end I have a reprogrammable BIOS chip, I could flash on there whatever I want. I'm far from knowledgeable enough to pull that off though, but maybe someone on ps2-home/psx-place knows whether or not it would be feasible.

I'm probably just overthinking it and just plugging the FMCB card with the savegames into another console works, I will try that for sure!

 

[thedrew]

Yeah software is not my thing either...but I totally understand the nostalgic factor involved with the memory card. I don't use VMC with MX4SIO to be honest, I save them to the FreeMcboot card in slot one. I would imagine you can still pop in that memory card to another PS2 and load saves just fine but I haven't tested that personally. We are always looking for ways to save space since portables are limited for space, so just thought this would be a great option for your awesome project!

 

[anuser]

I have two stuffs you will implement.
Search:
EEVblog 1384 - Halve Your Processor Power Consumption!
I don't think it would halve the power, but i think a 20+% reduction is pretty plausible in this old hardware, this was implemented in the PS3 generation directly on the chip, it would be VERY interesting to see what power reduction is possible on the PS2.

ALSO, forget your ethernet adaptor, you're searching for VOCORE, it runs OPENWRT, has ETH, SD, USB and WIFI and a few GPIOS to have some fun, can't beat it.

 

[Aurelio]

I have two stuffs you will implement.
Search:
EEVblog 1384 - Halve Your Processor Power Consumption!
I don't think it would halve the power, but i think a 20+% reduction is pretty plausible in this old hardware, this was implemented in the PS3 generation directly on the chip, it would be VERY interesting to see what power reduction is possible on the PS2.

ALSO, forget your ethernet adaptor, you're searching for VOCORE, it runs OPENWRT, has ETH, SD, USB and WIFI and a few GPIOS to have some fun, can't beat it.

Dude, that was an April's fool video lol

 

[Tschicki]

ALSO, forget your ethernet adaptor, you're searching for VOCORE, it runs OPENWRT, has ETH, SD, USB and WIFI and a few GPIOS to have some fun, can't beat it.

I appreciate the suggestion, the VoCore2 looks pretty cool actually. I've seen that people were able to get samba working on the Mediatek MT7628 (real shame that you can only get it on aliexpress), so it might be feasible to use it on a PS2. However, I have decided to ditch the SMB game loading entirely and focus on the MX4SIO after running a couple of tests.

Now that I'm already typing a reply, I can also just give an update.

MX4SIO
As I mentioned already, I will be switching to the MX4SIO for running games on my portable. I got myself a clone MX4SIO memory card and a 128GB samsung SD card and tested ~25 of my favorite games on my prototype. And I have to say that I'm very impressed with the performance when using the latest OPL beta, there were only 3 games that did not work at all. Loading speed is noticably slower than SMB loading, I noticed it especially in GTA SA, where the terrain loading couldn't keep up with the hydra jet quite frequently. When comparing it to the disc version of the game the performance is about the same, so I guess I'm just spoiled by HDD/SMB loading. You could call the MX4SIO more "realistic".
I also tested the same games with SMB loading on my prototype and HDD loading on my 39k PS2 to get a reference for the compatibility. SMB was running all the games just fine and on the HDD only 2 games were broken.

Another important thing for me was that transferring savegames should be as easy as plugging the FMCB memory card into another console. When I have a portable in the future, I want to continue playing the savegames on my TV using my softmodded 39k PS2 without much hassle.
I gave it a try and I can report that it kinda works. The 39k was always booting from the memory card instead of the hard drive in the beginning, but after changing some settings in the FMCB configurator it now boots into FHDB by default. The issue now is that for some reason the 39k takes ages to boot into FHDB when the FMCB memory card is plugged.
The next problem to overcome was OPL. The OPL settings are saved to the FMCB memory card on my prototype and to the HDD on my 39k. Now when I start OPL on my 39k and the memory card is plugged, it always reads the settings from the memory card. That broke OPL, because I was using different OPL versions on the two consoles. I kind of solved it by using the same OPL version and let them share the same settings, but that is still not a perfect solution. Now the artworks are still kind of broken and I guess the compatibility mode settings might be broken too.
I guess I can live with that. It really only is a problem on PS2 fat consoles with FHDB, if I get a slim PS2 with SMB server there should be zero issues.

So the conclusion for myself:

• Is the MX4SIO better than SMB loading?
  • No. There are quite some compromises to make.
• Is the performance good enough to justify switching to the MX4SIO in my portable?
  • Yes. Considering that the MX4SIO development is relatively new, I see lots of improvements in upcoming OPL versions. It also saves quite a bit of space and the power savings of ~1W should also be considered. There is also less complexity and fewer components that could break.Transferring savegames is a bit of a pain right now, but I'm sure I can find a better solution in the future. At this point I'm totally convinced that the MX4SIO is the best solution for playing games on a portable PS2.

Now that the MX4SIO is out of the way I can give an update on the other things I was working on.

BIOS Module with CE fix
Two modules were assembled & tested and they work perfectly fine. One module has the S29JL064J55 and the other one has the S29JL032J60 to try both speed options. Both of them work and that leaves me with 3 working NOR flash chips to use in my system. Let's also use the time and celebrate the first bodge wire on my prototype! yay!
This was also the last puzzle piece to get the functionality I want out of my reverse engineered mainboard. Now I'm happy with all features and everything is tested and working at this point.

Power Management
There was significant progress on the design of a first prototype. I decided to split the design into 2 boards for flexibility, a regulator board and a base board. The regulator board has all the power regulators for the PS2 and plugs into the base board. The base board includes the SysCon and probably some means to measure the power input/output. The base board is not ready yet, so let's focus on the regulator board:

Following my rough power supply concept I was searching for suitable buck converter ICs to satisfy my requirements.
There were 2 possible directions to take in the beginning:

• an all-in-one power management IC with multiple outputs, like the ADP5052
• discrete regulators for the rails

The ADP5052 is a pretty nice and compact solution, but it didn't quite fit any of my requirements. The current limits are a bit awkward, the 1V25 line requires 2x 10mm inductors to get decent efficiency, the integrated LDO does not support my battery voltage, the Vout/Vin ratio for the 5V rail was not big enough (it will require 100% duty cycle operation to meet my requirements), the PG does not cover all channels, ....
I did quite some calculations and comparisons, but what ultimately made me go for tha latter approach was flexibility. If I'm not happy with the performance of one rail of the integrated solution, I can ditch the whole chip and I have nothing left. When I have discrete buck converters, I can tailor the features perfectly to my needs (at the cost of added complexity and BOM count, of course)

In an effort to find a good compromise between size, efficiency, cost and my requirements, I have selected the following chips for the first board:

• MPQ8626GD for the 1,25V rail
• TPS629210 for the 3V5, 5V (100% duty cycle operation) and SysCon power rail. Reusing the same chip reduces the BOM count
• ADP123AUJZ for the 2V5 and 1V75 rails
• TPS70933DBVR for the standby regulator (RTC + power switch, low Iq)

Some design notes for the prototype:
The regulator board features a BAT and CHARGE input, in case I need it. There is a charge_detect signal that is triggered by applying a voltage to the CHARGE input. It bypasses the power switch and turns the SysCon on automatically when a charger is plugged. I will need that for handling the charging process and for displaying the SOC. The 1V25 regulator currently has a trimpot in the feedback divider on the bottom layer, that will make undervolting the EE easier. The pins are arranged with a 100mil pitch for using the board on prototyping PCBs. I would like to keep the Iq of the whole system in off state below a couple 100uA, that was also an important consideration when choosing the buck regulators.

The PCB design is 90% finished and the regulators require about 24mmx22mm of space. The layout is still a bit messy for my taste, but optimizing it more for a first prototype would be a waste of time. My plan is to order the PCBs and the components in the upcoming days.

SysCon
The uC for the SysCon was also selected. I will be using the SM32L476, mainly because I found some in my junk box. It's low power, has lots of memory and should be plenty fast for my application. I'm currently working on the pinout of the SysCon and the schematics of the base board for the power management.
The base board might already include some peripherals of the SysCon to play around with.

Soft Power Switch
A quick&dirty prototype of the soft power switch was designed and ordered and I really hope that it works. I'm not a huge fan of the MOSFET based circuits floating around on the internet, so I came up with a circuit based on the 74LVC1G74 D flip-flop. The fact that I have a standby 3.3V rail makes this much easier.
This is how I expect it to behave:
The switch would feature a long press to turn on + long press to turn off - adjustable via R102 and C101. The 74LVC1G74 is edge triggered and has schmitt trigger action on the clock input, so the slow rise time of the power button input should not affect it. The idea of D101 in the circuit is to discharge the capacitor immediately via R101 when the power button is not pressed, otherwise the circuit would be locked for a couple of seconds after each button press. The latch should be reset to a defined (off) state by C104 when applying power, because /RD needs longer to settle. The SysCon has the possibility to force the system on and off via the asynchronous set and reset inputs, overwriting the power button. SYS_VCC_EN feeds into the EN pin of the buck converter powering the SysCon, it can only be bypassed via the charge_detect signal. Powering on and off the rest of the system will then be taken care of by the SysCon. The quiescent current should be pretty low in the uA range.

I don't know whether the circuit really works because I couldn't simulate it (my multisim license expired), but in my mind it should work in this configuration.
We will find out more when I get the power switch assembled!

 

[Fly_5]

I am really enthusiastic about your project, when you finish it, will you make your PCBs to order? I would be delighted to buy one from you. Regards