Worklog Some PS2 Project

[mixa232323]

Valid data output after OE# low 30ns;
AFAIK this is only true when the chip receives the address min. 40ns before OE goes LOW, as the max 70ns access time (address->output) is still there. You can see it in the timing diagram in the datasheet. Correct me if I'm wrong though!

The EE outputs the 22 bit address almost synchronously with OE. According to my captures, the addresses are output about 10ns (average) before OE goes LOW, after that the MX29LV320ETTI-70G still needs max 60ns to output valid data. The smallest OE low pulses I've seen are about 120ns-140ns long.
The only open question here is where the EE reads the data within those 120-140ns. If the EE reads them in the center of the pulse, the timing might be very tight in some situations and that's my only explanation for the MX29LV320ETTI-70G not working.
I could give my CE fix a try to see what happens, but as the mainbaord did not even boot with this chip I don't have much hope!

In model GH-40-52 ROM MX23L6400AYC-10G 100ns. I soldered in GH-72-42 MX29LV320ATTC-90 90ns. Works!

 

[Nostars240]

Please make sure to double-check that USB works at 5.3V input. The 4.5V you're measuring is without load I assume, when you connect some load to the USB port (eg. USB stick) I would expect that voltage to drop significantly.

Okay, I will do it right now and tell results

 

[Nostars240]

Okay, I will do it right now and tell results

Forgot to write when finished, anyway USB stablely works even on 4.2v, I guess it can work from lower voltage, I think it’s 3.3v logic and it can work from 3.3v too.

 

[mixa232323]

Valid data output after OE# low 30ns;
AFAIK this is only true when the chip receives the address min. 40ns before OE goes LOW, as the max 70ns access time (address->output) is still there. You can see it in the timing diagram in the datasheet. Correct me if I'm wrong though!

The EE outputs the 22 bit address almost synchronously with OE. According to my captures, the addresses are output about 10ns (average) before OE goes LOW, after that the MX29LV320ETTI-70G still needs max 60ns to output valid data. The smallest OE low pulses I've seen are about 120ns-140ns long.
The only open question here is where the EE reads the data within those 120-140ns. If the EE reads them in the center of the pulse, the timing might be very tight in some situations and that's my only explanation for the MX29LV320ETTI-70G not working.
I could give my CE fix a try to see what happens, but as the mainbaord did not even boot with this chip I don't have much hope!

If you look in the datasheet for the MX23L6414, you can see that the numbering of the CE pins starts from 0. In the PS2 ROM, CE1 and CE2. I am sure that there is an address decoder inside the ROM which activates CE0 when using a specific address space. It is not correct to use inverted /CS5 due to possible conflicts with other peripherals built into the CPU.

And now the most interesting.

The reason that one of the ROM chips is not its speed. Data is fixed not when the /RD level is lowered and not in the center, but at the moment the /RD level is raised. Everything is much easier. The current strength of the periphery is higher than that of the S29PL064J55BFI070 because the data from the ROM was suppressed.
I found and tested a simple solution. Here it is.

The permissible resistance of the resistors must be tested.
I have 560 ohm resistors. Everything is working.

 

[Tschicki]

If you look in the datasheet for the MX23L6414, you can see that the numbering of the CE pins starts from 0. In the PS2 ROM, CE1 and CE2. I am sure that there is an address decoder inside the ROM which activates CE0 when using a specific address space. It is not correct to use inverted /CS5 due to possible conflicts with other peripherals built into the CPU.

And now the most interesting.

The reason that one of the ROM chips is not its speed. Data is fixed not when the /RD level is lowered and not in the center, but at the moment the /RD level is raised. Everything is much easier. The current strength of the periphery is higher than that of the S29PL064J55BFI070 because the data from the ROM was suppressed.
I found and tested a simple solution. Here it is.

The permissible resistance of the resistors must be tested.
I have 560 ohm resistors. Everything is working.

Thank you, that is some very valuable input! THIS is exactly why I like this website so much and why I decided to post my progress! I really appreciate that people have a critical look at the stuff I'm doing and point out the things to improve by contributing their experiencees and knowledge!

After I saw your post I started searching in my junk pile and found a couple of MX29LV320ETTI-70G I was using back then. I soldered one to my BIOS module with the inverted /XHCE and it was booting just fine! That would confirm your statement about the access speed, it does seem like it's not that critical. Nice, because the MX29LV320ETTI-70G is about half the price of the other flash chips I've used so far.
I know my current solution using the DSP CE is not ideal and I do agree with you about the possible conflicts. But there I just have to mention that the implementation was stable for at least 20h of testing on my custom mainboard.

Your idea about limiting the output drive is very clever! Looking back, one of my theories was actually the difference in output drive, but I would have never had the idea to put series resistors on the data lines to limit it artificially. This also solves the awkward situation with the CE, as you can just tie it to GND + it saves one IC (the inverter) and I can reuse the same value resistors that are already on the mainboard, makes the BOM nicer!
Overall, this looks like a more elegant solution and I just had to give it a try immediately. I cut the 8 data traces on the bottom of the BIOS module and soldered 560 ohm resistors in series, as you suggested. I also removed the inverter and tied the CE to GND.
And it boots! I will leave it like that for all upcoming testing sessions and if it turns out to be stable I will implement it in my design! Maybe it would also be interesting to check the signals on the scope at some point.

 

[supertazon]

Oh man I don’t understand anything about what’s going on but I feel your enthusiasm in all of your posts and this is just amazing! Keep up the great work!

 

[mixa232323]

Thank you, that is some very valuable input! THIS is exactly why I like this website so much and why I decided to post my progress! I really appreciate that people have a critical look at the stuff I'm doing and point out the things to improve by contributing their experiencees and knowledge!

After I saw your post I started searching in my junk pile and found a couple of MX29LV320ETTI-70G I was using back then. I soldered one to my BIOS module with the inverted /XHCE and it was booting just fine! That would confirm your statement about the access speed, it does seem like it's not that critical. Nice, because the MX29LV320ETTI-70G is about half the price of the other flash chips I've used so far.
I know my current solution using the DSP CE is not ideal and I do agree with you about the possible conflicts. But there I just have to mention that the implementation was stable for at least 20h of testing on my custom mainboard.

Your idea about limiting the output drive is very clever! Looking back, one of my theories was actually the difference in output drive, but I would have never had the idea to put series resistors on the data lines to limit it artificially. This also solves the awkward situation with the CE, as you can just tie it to GND + it saves one IC (the inverter) and I can reuse the same value resistors that are already on the mainboard, makes the BOM nicer!
Overall, this looks like a more elegant solution and I just had to give it a try immediately. I cut the 8 data traces on the bottom of the BIOS module and soldered 560 ohm resistors in series, as you suggested. I also removed the inverter and tied the CE to GND.
And it boots! I will leave it like that for all upcoming testing sessions and if it turns out to be stable I will implement it in my design! Maybe it would also be interesting to check the signals on the scope at some point.

I was looking for a way to remove two chips. But I accidentally solved other problems and decided to write to you about the results.
I will gnaw out these two uncomfortable microcircuits with my teeth. They are redundant. But we need to come up with a way to bypass the binding. This will allow you to place the power controller and power elements on the same board. There is still a problem that you have not solved. Power start sequence. If it is broken the CPU may die. You're in luck so far.

 

[Goodie175]

This is absolutely amazing! Redesigning the entire system and stripping it down to actual bare minimums is insanely impressive! What is the long term goal for this project if you don't mind me asking? Are you going to attempt the smallest PS2 build? because from what i see here you can most definitely pull it off.

 

[Mister M]

Thank you, that is some very valuable input! THIS is exactly why I like this website so much and why I decided to post my progress! I really appreciate that people have a critical look at the stuff I'm doing and point out the things to improve by contributing their experiencees and knowledge!

This is excellent, I think so too. The idea of publicizing the work is something very useful for the community, we provide the opportunity for others to work on improvements for the portable console scene. I am happy and excited with your progress in this work, immensely happy to see this idea working. And to think that they said when I started that this would be impossible, nothing is impossible for those who go in search of their goals.

 

[Tschicki]

Update time!

It’s been quite a while since the last update, but I’ve been busy working on the project! There was quite some progress on a couple of topics.

Battery and charge management:
The board was designed and ordered in April, but it took 3 weeks to arrive. It’s not my finest layout, mainly because I was in a rush to order everything before a business trip. Was a good decision though, looking at the long delivery time…

The board includes 3 main components:

• The BQ25792 battery management IC
• STUSB4500 USB PD controller
• MAX17205G fuel gauge

Assembly was straight forward and I even found two matching 2200mAh batteries on my junk pile for testing. The good thing about the BQ25792 and the STUSB4500 is that they can operate in stand-alone mode, so I was able to give the board a try before writing some code.

The outcome was that the PD negotiation and the battery discharge path were working as expected. There is just one annoying thing about the STUSB4500: it negotiates 20V from factory. I made the wise decision to specify all components for 20V operation, but in the end, I just want 15V@3A max.

The most important thing was not working: charging. It took almost 2h of troubleshooting to find out that I messed up a connection on the BQ. The SDRV charge pump output was tied directly to battery+ instead of a decoupling capacitor to battery+. It was a stupid mistake on my end, but looking back, the description in the datasheet might be a bit misleading for a non-native speaker:

So… back to the workbench. I desoldered the BQ, disconnected the SDRV pin, applied UV soldermask, soldered the BQ back on and attached the required decoupling cap. (see if you can find the bodge in the picture)

And surprise, charging was working too!

The MAX17205G was impossible to test without a firmware, so I kept ignoring it for the moment. To limit the number of possible failures, I actually even bypassed the MAX circuit (the red wire in the picture). In the meantime, I also found the MAX17320. It might be a better choice, as it has pretty much the same features, but includes battery protection by default. Will think about it…

At that point, everything that could be tested without a firmware was tested. Which means SysCon time…

SysCon:
I was already in the process of designing a PCB for the SysCon when I decided to do it the quick & dirty way on a protoboard. It makes changing the pinout much easier.

Then for the last 2 weeks I was working on a simple firmware to control the power management.
Programming is my biggest weakness, that’s why it always takes me a bit longer
I wanted to write the HAL for the BQ and the STUSB from scratch to adapt them to my needs and I started with the register maps. There, I took the long and safe way by doing everything with masks and shifts instead of bitfields, it should make the code more portable.
Even though I’m using the STM32 HAL for all the uC stuff, I added another layer of abstraction to compress all references to the STM32 HAL into a single source file. It will make my life easier in case I have to port the code to a PIC or something. It might happen, because I’m not planning to stay with the L476. It’s way too much (and way too expensive for what it does). But the replacement will most likely be another STM32, maybe something in the F0 or L0 range.

Now I have most of the code I need to control the BQ and STUSB, the MAX17205 is still missing.

Next step was testing:
Because I didn’t want to update the STUSB NVM to only negotiate 15V max by default, my first idea was to re-negotiate the PDO contract after booting. The state machine looked something like this:

Charger plugged -> init STUSB PDO -> renegotiate PDO with source -> init BQ with current PDO -> enable charging

The renegotiation part was working, the charger started at 20V and after setting the PDOs it changed to 15V. The big problem was that the BQ did not like this. I could never get it to charge after the initialization and it ended up in a weird state. The charge status bits said “fast charge”, the STAT pin was LOW (indicates charging) and all fault bits were ok – but the charge current was 0. No idea how the BQ can end up in this state. It almost looks like it crashed somehow, only reinserting the batteries fixed it. Charging was working fine when I skipped the 15V renegotiation. It could be that the BQ cannot handle the situation when the STUSB discharges the VBUS to 0V for a couple of milliseconds before switching to the new contract, but it shouldn’t care when it’s not currently charging.

Skipping the discharge (there is a bit for that) or increasing the discharge time might have improved it, but the overall situation was too sketchy for me. Instead, I tried to update the STUSB NVM to negotiate 15V max by default, that way I can skip the re-negotiation altogether.

This turned out to be a real pain in the ass, the STUSB4500 documentation is the worst I’ve seen in a long time. The functionality of lots of bits is not properly explained, so the usual approach was always trial and error. The next issue was that the register map in the software guide is not complete, there are reserved registers that do actually have a purpose + in the case of the NVM there are plenty of undocumented registers/functions. The only support from ST is to “check out the official STUSB4500 library, you will find everything there”. This is exactly what I had to do… I found the undocumented registers in one of their header files and I had to reverse-engineer the NVM update functions to implement them in my code. I still have no idea what I’m actually writing to the NVM, the data array was exported by ST’s configuration software and there is no documentation on what each byte does. It somehow works though, now I have a function to update the NVM.

After that was sorted out, I tried charging again and now it works reliably. The bonus of this approach is that I don’t really have to interface with the STUSB4500 anymore, as everything is handled automatically. Now I can just observe the two PDO PG pins and from that I can obtain the input current limit I have to set in the BQ.

Adding the power switch:
The next thing to implement was the soft power switch. This one was very interesting…

A quick observation on the charger I’m using: The voltage difference between the charger GND and my PC UCB GND is about 70V RMS. There is no energy behind it, because you can load it down to a couple of mV using a 10k resistor. It is enough to cause weird things though… grounding issues… my favorite issues.

One thing that happens is that my debugger loses the JTAG connection to the SysCon when I touch the USB C socket on the battery management board with the USB C cable. The SysCon keeps operating just fine though. To fix this issue for debugging, I just shorted the shields of the charger’s second USB C port and one of my PC’s USBs, this seems to do the trick for now.

The more concerning issue could be observed on the power switch: when hotplugging the charger, it would sometimes show random behavior. Sometimes it turned off, sometimes it turned on. I’m pretty sure that it was not caused by the grounding issues with my PC, because it also happened when the setup was floating.
The current power management implementation states that the SysCon has to turn on to handle charging when a charger is plugged. I was doing it by latching the power switch directly from the ATTACH output of the STUSB, this pin indicates an attached charger. Turns out the pin state is not defined when no charger is plugged (as the STUSB is unpowered there to reduce quiescent current). It’s a little oversight on my end and this finally convinced me to ditch the soft latching power switch altogether. The only benefit it would provide is that you can force the system off in case the SysCon crashes.

It was time to find a new solution:
My next idea was to handle the latching in firmware. I can just hook up the push button to the EN of the SysCon supply rail and have a PMOS in parallel. The PMOS is controlled by the SysCon and the first thing after booting is to drive this pin low. That way, the system stays on. To determine when the system should turn off, I've included a diode in series with the push button and I’m getting the button state from there.
For powering the SysCon automatically when hotplugging a charger, I make use of my charge detect circuitry on the regulator board. It is essentially just a 3.3V Zener diode connected to VBUS, so charge_detect will go HIGH as soon as the STUSB enabled VBUS.

This implementation works very well so far, the only drawback is that shutting down the system is handled by the SysCon. If the SysCon encounters an unhandled exception, it will not be able to turn off the system (this happened already, that’s how I know ). I will have to take good care when writing the code to always allow the system to shut down, if I proceed in this direction.

With all the circuitry working, it was time to implement a simple state machine to handle charging, power on and power off. It's actually 2 state machines, one for charging and one to keep track of the system state.
I will spare you with more boring details, here is the next achievement for the project. My custom mainboard is able to run off batteries for the first time. You can hotplug a charger and the SysCon is able to turn on and off the PS2 on its own. There are still some quirks with my state machine, error handling is mostly missing for example, but for sure I will improve the code.

For now it works:

Now that it “works”, I’m thinking about things to test/measure to verify that everything works as expected. The only thing I measured so far is the battery quiescent current of the whole system in standby mode and full batteries: ~28uA (including the PS2 RTC). Looks good for now!

Power management architecture:

I’m handling this topic separately, because it does not have a big influence on all the SysCon stuff.

The main reason for being so focused on power sequencing is an issue I’ve noticed with all custom regulator modifications I’ve done in the last 6 months. This is also present on my modified and custom board. In about 1 of 20 power cycles, the red power LED does not turn on and the system consumes ~1.5A. Resetting the power always fixes the problem. I can think of 2 possible issues:

The first would be the fact that I always removed the POR chip of the MechaCon. The second would be power sequencing, because I never noticed this issue before removing the stock regulators.

I was thinking about how to best implement the power sequencing in the last couple of weeks, but always came to the same conclusion: it is not possible on the current custom mainboard revision. This is because I tied the SBY 3V5 and SBY 1V8 rails to the 3V5 ad 1V8 rails internally, without a way to separate them. It will never allow me to power the MechaCon first.

If I’m aiming for reliability, I might have to go for the stock power supply architecture. That means I will have to allow the MechaCon to turn on the voltage rails. It has the benefit that I can give the MechaCon a purpose again (because now it’s not doing much) and I don’t have to handle the sequencing in the SysCon (that will save me quite some pins).

To test whether or not this fixes the issue, I took my trusty modified 79k mainboard and hooked up my power management system to imitate the stock regulators. To do it I designed a little PCB with two load switches for enabling the 3V5 and 1V8 rails (they are just tied to the standby rails, no new regulators needed). They are soldered to the mainboard and controlled by the MechaCon. On top of that, the MechaCon controls the 1V25 regulator on the regulator board. The 5V, 2V5, SBY 3V5 and SBY 1V8 rails are still provided by the regulator board and enabled by the SysCon.
With this setup, the MechaCon controls the sequencing of the 1V25, 1V8 and 3V5 rails. The other rails don’t really need sequencing and I just turn them on at the same time using the SysCon.

To replace the POR chip that I removed, I added the LM809M3-2.63 reset IC from my reverse engineered memory card instead. It should keep the MechaCon in reset until the SBY 3V5 rail is high enough.

Here is the setup:

First tests were very successful! There was not a single hiccup, but I will do some more testing to reproduce the issues I had. If this is more reliable, I will implement the changes into the next revision of my mainboard.

SD memory card:
I really wanted a good reason to try the new cheap flex PCB service from JLC and the first useful thing that crossed my mind is a compact memory card. One of the requirements for my portable is a memory card socket and it would be a good compromise if I could somehow develop a smaller memory card for it.

This is what I did, the new memory card has the size and form factor of an SD card. Not just that, the pinout is also compatible with MX4SIO memory cards. With a modified MX4SIO, I can connect this memory card to any PS2. The only thing to modify is the ACK line: the 47R resistor to GND on the MX4SIO needs to be removed and the ACK needs to be connected to pin 9 of the SD socket.
On my portable I could even include 2 full size SD sockets for the memory card and the MX4SIO. Using either the card detect or the lock switch, I could differentiate between the two. That way I could even swap the cards or connect 2 memory cards for copying savegames.

Pretty interesting ideas, but I will think about the benefits and drawbacks a little more, before I implement something!

The card itself works so far. The flex PCB looks nice and the price is a real game changer for flex PCBs. Because I’m constrained to ~1.45mm in height, I ordered the thinnest PCB (0.11mm) and removed the stiffener completely. This makes soldering the components a bit harder, but it is needed for the card to fit. Then I just fuse the flex PCB to a 3D printed frame to make it rigid. The cutout for the components could then be filled with epoxy to seal everything. Done. Looks really cute!

The only concerning thing is the ENIG plating, the pins look really scratched already after about 20 mating cycles. I don’t see a hard gold option on the JLC configurator, so the only option for the future might be to increase the copper thickness to 1/2oz (currently 1/3oz).

Some other stuff I was working on:
Now that I have my Fluke 52, I was playing around with temperature measurements on the EE. With my fan I get around 34°C using 1V core voltage and ~37°C at 1.25V. This matches the readings from PS2Temps, the MechaCon readings just take about 10min longer to settle (because the temperature sensor is next to the EE). Good to know that using PS2Temp is a good option to observe the EE temperature.

I started evaluating different fans and thinking about a cooling solution for the portable. On the pictures above you can see the KDB0305HA3-00 blower fan. It's 30x30x3.5mm and using the same heatsink as before, it manages to keep the EE at 38°C on 1V. It's very loud though, that's a no-go.
The next fan on my list is the sepa HY45T05A. It's 45x45x5mm and a lot more silent. Another interesting option might be a Nintendo Switch fan.
This topic is still ongoing, I'm also looking for suitable heat sinks, as the one I have is not ideal for blower fans.

I should really do more frequent updates, this post got pretty long again!

 

[Fly_5]

Great job, your progress is incredible.

 

[anuser]

Update time!

Please, please, really please check your PM

 

[anuser]

Now we get to the cheating part:
The 90k mainboard has some sort of brownout protection for the MechaCon (not sure about 79k right now). It seems to be an external chip and the location can be seen in the picture below. When the IC is in place, it looks like the MechaCon is held in RESET as soon as the input voltage is below ~6.5V. When I remove this IC my 90k system also works normally below 6.5V
View attachment 27203

Question, i had a board with a burned power supply, i bypassed the 7805`s and tried to run the board on 5v, it worked for a few minutes then bricked itself, is the brownout protection broken? can i run it without this ci without much problems? i also got a 8.5v brick from a fat PS2, can i use it to power my board or did i fry the board trying to run it on 8.5V? i made sure to remove the 7805 bypass way before i ever got the 8.5v brick so there's no possibility it was this, my guess is that the mosfet for the regulators are fried from excess of TON, but it could very well be the brownout protection. Thanks.
OBS:i burned the power supply out of the board, did some dumb stuff and it let the magic smoke, didn't connect it to the board so the board was fine when i tried running on 5v

 

[mixa232323]

SD memory card:
I really wanted a good reason to try the new cheap flex PCB service from JLC and the first useful thing that crossed my mind is a compact memory card. One of the requirements for my portable is a memory card socket and it would be a good compromise if I could somehow develop a smaller memory card for it.

This is what I did, the new memory card has the size and form factor of an SD card. Not just that, the pinout is also compatible with MX4SIO memory cards. With a modified MX4SIO, I can connect this memory card to any PS2. The only thing to modify is the ACK line: the 47R resistor to GND on the MX4SIO needs to be removed and the ACK needs to be connected to pin 9 of the SD socket.
On my portable I could even include 2 full size SD sockets for the memory card and the MX4SIO. Using either the card detect or the lock switch, I could differentiate between the two. That way I could even swap the cards or connect 2 memory cards for copying savegames.

I think you will understand what this link is about. And where to apply it.

MII instead of RMII: receiving is not possible - ESP32 Forum

Espressif ESP32 Official Forum

www.esp32.com

BCM5241

I'm not sure the pinout is 100% correct

 

[anuser]

I think you will understand what this link is about. And where to apply it.

Don't bother, it's outdated, i'm doing something with maximus32, your link is useless to this case. You wanna know why? search "vocore", and consider that you can use the GPIOs to bitbang an SPI interface to serve OPL the preprocessed files it needs without overhead while connecting to the internet, heck we can make a VPN to connect everyone using the vocore and share files, or even play directly from the network.

 

[mixa232323]

Don't bother, it's outdated, i'm doing something with maximus32, your link is useless to this case. You wanna know why? search "vocore", and consider that you can use the GPIOs to bitbang an SPI interface to serve OPL the preprocessed files it needs without overhead while connecting to the internet, heck we can make a VPN to connect everyone using the vocore and share files, or even play directly from the network.

I meant another function. Wi-Fi for the network, bluetooth for headphones and removing the BCM5241 chip from the circuit.

 

[anuser]

I meant another function. Wi-Fi for the network, bluetooth for headphones and removing the BCM5241 chip from the circuit.

Do you have any idea why you can't play online while using OPL via SMB? you would have to remake the entire network stack and create patches for calls for a lot of games, do you have any idea how even more complicated it would be to write a stack for wifi, let alone port the wifi drivers for an odd cpu, nevermind finding a board that has wifi and bluetooth in a an old parallel PCI format, and the price and availability for one even if you find it.
With vocore i can make a SMB NAS that bottlenecks the ether port because it's reading USB2.0, put a capture card and stream the video and audio via WIFi, i can port a joystick emulator from arduino to it so i can get the joystick data from the client side, i can use a GPIO to turn on or off the ps2, and make an app to play the stream while sending joystick data directly to the ps2 from a cellphone, heck i can probably add a bluetooth dongle to the vocore and use another gpio as pairing button for the bluetooth headphone, even without the vocore there is bluetooth transmitters that can be added to read the audio output and send it via bluetooth to the headphone and that wouldn't need to bother the vocore with overhead and be way too reliable.

 

[mixa232323]

Do you have any idea why you can't play online while using OPL via SMB? you would have to remake the entire network stack and create patches for calls for a lot of games, do you have any idea how even more complicated it would be to write a stack for wifi, let alone port the wifi drivers for an odd cpu, nevermind finding a board that has wifi and bluetooth in a an old parallel PCI format, and the price and availability for one even if you find it.
With vocore i can make a SMB NAS that bottlenecks the ether port because it's reading USB2.0, put a capture card and stream the video and audio via WIFi, i can port a joystick emulator from arduino to it so i can get the joystick data from the client side, i can use a GPIO to turn on or off the ps2, and make an app to play the stream while sending joystick data directly to the ps2 from a cellphone, heck i can probably add a bluetooth dongle to the vocore and use another gpio as pairing button for the bluetooth headphone, even without the vocore there is bluetooth transmitters that can be added to read the audio output and send it via bluetooth to the headphone and that wouldn't need to bother the vocore with overhead and be way too reliable.

esp32 has 2 cores at 240MHz. SMB NAS will be on it.

 

[anuser]

esp32 has 2 cores at 240MHz. SMB NAS will be on it.

esp doesn't have ram (320kb) to be a good NAS, heck it can't be an HTTP server that's worth a damn, and performance wise it's one core at 240mhz because nobody developing SAMBA for it would be crazy or dumb enough to use 2 cores, the overhead for multicore easily would surpass any gains of having other processor, let alone that even samba doesn't fit in the internal memory, and it's usb stack is bitbanged and doesn't have support for any file system.
Even if you spent your time overcoming all that, the result would be pissy performance that's worse than ps2's USB 1.1, and the price difference for a vocore isn't that steep.

 

[Tschicki]

I really appreciate the idea of replacing the BCM5241 with something else to get wifi, but I don't think I have the time and knowledge to implement something like that.
The vocore sounds interesting too, but I would only use it for SMB loading. It's already decided that I use the MX4SIO, but I will think about an option to exchange the MX4SIO with a vocore when I do the final design.

Anyway, here is a small update!

I'm still working on implementing all features into the power management, mainly the state machine and error handling were improved. Now the state machine even has a check for valid state transitions. The ultimate way of "handling" exceptions is now printing specific error codes and gracefully shutting down the system. This will change in the future, but for now I feel a little bit safer

Speaking of printing error codes: I got a UART running now for printing debug information to a terminal. This really helps with debugging, because I can just passively observe the system states and outputs. The debugger was really annoying, it always needs to stay connected to the target (which is hard when the target is turning on and off all the time).

The next cool thing I got working is the "dynamic" input current limit. The syscon now checks the charger's capabilites and adjusts the USB input curent limit accordingly to avoid overloading the source. It now supports 2 input current limits with the option to extend it to 4. Plugging the system into a USB2 port (or any other unknown source) now limits the current to 500mA, USB C PD chargers are supported with 5V 3A, 9V 3A and 15V 3A.
Still not 100% happy with the implementation, because the STUSB4500 is poorly documented and it's very hard to get the information I want from the chip. If someone has experience with the STUSB, I would appreciate a little hint on the "right" way to determine the source capabilities!

Now that I can plug the system into any USB2 port, I got the idea of connecting a simple USB-UART bridge to the D+/D- of the USB C charging socket. It would allow for debugging, updating the syscon firmware, updating parameters and possibly even updating the video processor without opening the portable. This would provide more value to me than some other uses (e.g. loading games onto the SD card via USB), will think about it...

Then I was working on the fuel gauge and battery protector. There was a decision to ditch the MAX17205 for now and to use a MAX17320 instead. It's a fuel gauge that provides battery balancing and a highly configurable protector for 2S packs. The PCB was designed and ordered already + the components should be on their way too. This particular PCB a bit of a hot mess right now, because it connects between the battery pack and battery management board and I need to solder some wires to connect the serial interface. Below you can see the current draft schematics.

The progress on the driver code is looking good so far. The register map is complete enough (who would have expected a fuel gauge to have THAT many registers?) and I've prepared functions to write the protector and fuel gauge configurations into NVM. A usable configuration for the IC was already exported from the MAX17320 eval board software, which has a nice GUI to configure all features and parameters. The config will need some tweaking though, because there are A LOT of things you can specify. At least the prototype shouldn't catch fire immediately when using the current config...
Accessing volatile config registers and reading fuel gauge outputs will most likely be implemented this week. Then I can hopefully have a test firmware ready when I get all parts for the MAX17320.

The last thing I was working on is troubleshooting the random boot issues of my custom mainboard. In my last post I named 2 likely causes already:

The first would be the fact that I always removed the POR chip of the MechaCon. The second would be power sequencing, because I never noticed this issue before removing the stock regulators.

Through the power of the syscon I was able to troubleshoot case #1, which is the missing POR chip. To do the testing, I modified the syscon state maching to turn the PS2 on and off 100 times with highly controlled timings. Using the improved error handling, the syscon notices when the PS2 does not boot, throws an exception and resets the system. So, all I had to do was to power it up and check the UART, the rest was running automatically. I started the test with the unmodified mainboard and got a couple of error messages, which confirms that the testing method is good for reproducing the issue.
Then I soldered the LM809 voltage supervisor to 3.5V, GND and the mechacon reset testpoint on the mainboard. I'm 90% sure that the chip on the original mainboard handles the POR too, judging by the pinout.

With this modification, the code ran through another 100 cycles without an exception. Looks like I may have found the cause of the undefined bahavior...
My conclusion from this test: the mechacon either needs a proper POR or it just didn't like that I left this pin floating (maybe a pullup would do the job too)
To be 100% sure, I will include the LM809 in the next revision of the board.

So how to continue with the regulators? Keep the old architecture or allow the mechacon to handle the power sequencing? Judging by the test results I got, it should not be needed to implement "proper" sequencing. As the sequencing (by the mechacon) requires the power management architecture to be more complex (and does not provide sufficient benefit as far as I can tell), I tend to just omit this feature and keep switching all supply rails at once using the syscon.

When the power management is running (including fuel gauge & protection), the next task is to implement a gamepad emulator in the syscon. I will probably get some inspiration from the PS2+ and the overwhelming amount of information about the DS2 protocol floating around on the internet. After that, I may be ready to start looking into the video & audio output of the portable.