Retro Lite CM4: Handheld Gaming Console

[StonedEdge]

I don't think you need step 2 in this situation. You can safely power down your device by doing the software shutdown and then pulling GLOBAL_EN low.

However, you actually don't even need to pull GLOBAL_EN low if you are also pulling power to the 5V rail through some other circuit. Pulling GLOBAL_EN is about disabling the other 3.3V and 1.8V rails that is providing power to other parts of the PI so that you can get it into the lowest possible power state. However, disconnecting the 5V power source is the same as pulling the power cord on the Raspberry PI 4B affer you run the shutdown command, which most people do when they are using their PI's.

So to summarize I would do the following:
1. If you won't be able to turn off the 5V power to the CM4, then run a software shutdown followed by pulling the GLOBAL_EN pin low to get the PI into the lowest possible power state
- or -
2. If you are able to turn off the 5V power to the CM4, then run a software shutdown followed by killing the 5V power on to the CM4

Hi, thanks for your reply and advice! Btw, you’re the person who made their own CM4 handheld right that was 3D printed? I’m a huge fan, it turned out great! Hopefully this one will be just as good as yours. Can I ask how you managed to do battery monitoring? Did you just use a basic ADC reading of battery voltage and then output that value after doing some manipulation with the discharge curves? I’ve been looking into the MAX17055 as there seems to be a Linux driver available for it, but I don’t really know how trivial it would be to get a HUD display working for that.

Pretty confident we can get a basic ADC module working for battery status (full, low, shutdown) etc but it won’t be nearly as accurate as a proper fuel gauge.

Cheers! Looking forward to seeing improvements of your model

[juckettd]

For the battery monitoring I use the following circuit from TI:

https://www.digikey.com/en/products/det ... WT/5218172

This is a battery charging circuit that handles quick charging through negotation in the USB input.

[StonedEdge]

For the battery monitoring I use the following circuit from TI:

https://www.digikey.com/en/products/det ... WT/5218172

This is a battery charging circuit that handles quick charging through negotation in the USB input.

Ideally, I'd like to integrate the max17055 fuel gauge IC here from maxim integrated, control it over i2c bus via the Pi and display the SoC and remaining battery life on the display. ADC readings of voltage are not really ideal for reading the battery. Of course they will be OK for initiating shutdown sequence, that would still work too. That will be the next task Hopefully not too difficult to get some code working. I was going to use the 17043 from maxim, but without the current shunt resistor I doubt that under high loads its going to work too well. The gauges that don't use a current sense for couloumb counting (like the 17043) are going to be super inaccurate with a large current draw (like the cm4 console), because there is likely to be a large voltage drop from the internal cell resistance.

https://datasheets.maximintegrated.com/ ... X17055.pdf

[cleverca22]

vcell.png (12.85 KiB) Viewed 6264 times

soc.png (12.68 KiB) Viewed 6264 times

an example of graphing both voltage and "soc" from a https://www.sparkfun.com/products/10617 (MAX17043G+U)

The SOC register is a read-only register that displays
the state of charge of the cell as calculated by the
ModelGauge algorithm. The result is displayed as a
percentage of the cell’s full capacity. This register
automatically adapts to variation in battery size since
the MAX17043/MAX17044 naturally recognize relative
SOC.

this looks to be nearly identical to the part StonedEdge mentioned, and the graphs show the problem he was describing

in my case, the graph is from a pi1 running off a 2000mAh battery, while basically idle but driving a usb wifi chip, to report the numbers back to a graphing system

[StonedEdge]

Last CAD update for a while. We've finished everything and I've finalized the Digikey and LCSC bom, which came out to cost me a lot more than I had hoped but I knew this was going to be an expensive project anyway from the beginning, so no comment from my side. A lot of the cm4 modules we would like to use are sold out (that being the non-emmc (Lite) version with wireless, 4/8GB), so if anyone has a link/idea of when they would be available that would be appreciated. I know COVID has thrown a spanner in the works with the modules so I guess delays are unavoidable.

Next steps will be machining the case and ordering the PCBs to be assembled from PCBWay.

Enjoy,
Ben

[donvermo]

For the battery monitoring I use the following circuit from TI:

https://www.digikey.com/en/products/det ... WT/5218172

This is a battery charging circuit that handles quick charging through negotation in the USB input.

Ideally, I'd like to integrate the max17055 fuel gauge IC here from maxim integrated, control it over i2c bus via the Pi and display the SoC and remaining battery life on the display. ADC readings of voltage are not really ideal for reading the battery. Of course they will be OK for initiating shutdown sequence, that would still work too. That will be the next task Hopefully not too difficult to get some code working. I was going to use the 17043 from maxim, but without the current shunt resistor I doubt that under high loads its going to work too well. The gauges that don't use a current sense for couloumb counting (like the 17043) are going to be super inaccurate with a large current draw (like the cm4 console), because there is likely to be a large voltage drop from the internal cell resistance.

https://datasheets.maximintegrated.com/ ... X17055.pdf

I'm very curious to see the final result! In case you were still thinking about the battery status indication etc. I am going out on a limb here and am assuming that you will be using Retropie for emulation.

If that is the case then maybe this repository will be of help: https://github.com/d-rez/gbz_overlay
Which is essentially a script to display status messages like battery status on top of Retropie.

Looking forward to more updates!

[VirgoH]

Last CAD update for a while. We've finished everything and I've finalized the Digikey and LCSC bom, which came out to cost me a lot more than I had hoped but I knew this was going to be an expensive project anyway from the beginning, so no comment from my side. A lot of the cm4 modules we would like to use are sold out (that being the non-emmc (Lite) version with wireless, 4/8GB), so if anyone has a link/idea of when they would be available that would be appreciated. I know COVID has thrown a spanner in the works with the modules so I guess delays are unavoidable.

Next steps will be machining the case and ordering the PCBs to be assembled from PCBWay.

Enjoy,
Ben

I found these sites that seems to have the CM4 4gb Wireless, without emmc:

https://www.cytron.io/amp-p-raspberry-p ... m-and-emmc

https://www.newark.com/raspberry-pi/cm4 ... p/86AH2101

I hope this helps. Also, I'd totally buy one of these if you decide to sell them.

[StonedEdge]

Hi everyone.

A small update for you all on the progress of the case assets. All of the CAD work, as well as toolpathing in Fusion 360 has been completed and I'm proud to show you the first prototype front half, machined out of aluminum grade 6061 metal! I think it looks almost exactly like a Switch Lite, which is what we were aiming for when we first started prototyping our design. Of course, the screen is not a 5.5" screen (5") but without MIPI interfacing, we were limited to using a 5" IPS panel.



The next steps will be machining the back half and assembling the main PCB, which will house the CM4 and all other peripheral circuits. I have ordered myself a CM4 Lite with Wireless, as well as a small little microscope to hand solder the high density 90-pin connectors onto the the peripherals board. The code for button debouncing and BQ power management also needs to be written, as well as for the MAX17550 fuel gauge. We then finally need to machine our heatsink, which also will be done in aluminum. As for anodized finishes, I will probably go with cherry red. I am not sure what my project partner will go for, but I'm sure they will come out wonderfully!

Still a few months to go, but we hope to have this all finalized by the end of June at the earliest.

[StonedEdge]

One last picture for completeness! The engraving looks great, and Nintendo would like to know our location.

[StonedEdge]

Here is a couple of pictures of the PCB progress and case housing. Everything was hand soldered with the Hakko FX-888D soldering iron, including the Hirose high density 0.35mm pitch connectors.




We've finished the machining work and the cases are off for anodization tomorrow. I went with Irish Green Satin and my friend went with Atomic Purple Satin finish.







I am also waiting on my Switch Lite HDH-003 pouch cell before I can start testing anything as I don't have a bench PSU to work with right now.

[StonedEdge]

So I'm currently facing my first issues with RetroPie and getting a boot from the CM4. I'm getting a good unimpeded flow of current to the CM4 5v pins with no voltage drop. The 3v3 internal regulator also is working fine and is at 3.29v. My process to test that the CM4 is booting was as follows:

1) Flash this version of RetroPie onto my SD card using balenaEtcher -
https://github.com/RetroPie/RetroPie Setup/releases/download/4.7.1/retropie-buster-4.7.1-rpi4_400.img.gz
2) Attempt to see video out on HDMI1 port (not HDMI0 port) - no video on TV screen
3) Ping the CM4 WiFi via "Ping retropie" in the command prompt on my Windows PC - no ping response received from the Pi
4) Attempt to force HDMI1 output with the following command in config.txt - hdmi_force_hotplug:1=1
5) Check GLOBAL_EN and RUN_PG pins after boot connected to the ATtiny microcontroller - both are high logic when powered
6) Check SoC - warms up and gets hot

Starting to run out of ideas and thinking that it could potentially be my soldering job of the hirose connectors instead, or I've screwed something up in my schematic majorly that will call for a redesign. I really should have put test pads on the PCB so that I can easily probe things. I haven't checked the 1v8 regulator is working correctly because I can't reach it underneath the module. Is there any points I can probe on the top of the module so I don't have to probe the tiny little connectors?

I'm sharing the EAGLE board and schematic below for good measure - perhaps someone can find something that I can't that is causing issues. It's a little messy at the moment but I plan on cleaning them both up before we release it.

Cheers

Board
https://drive.google.com/file/d/1WDarA8 ... imLCBB1du4

Schematic
https://drive.google.com/file/d/1U4ZdT1 ... qpf8GdmiBI

[cleverca22]

Starting to run out of ideas and thinking that it could potentially be my soldering job of the hirose connectors instead, or I've screwed something up in my schematic majorly that will call for a redesign. I really should have put test pads on the PCB so that I can easily probe things. I haven't checked the 1v8 regulator is working correctly because I can't reach it underneath the module. Is there any points I can probe on the top of the module so I don't have to probe the tiny little connectors?

to rule out your soldering and IO board, try booting a regular raspi-os image instead, that will confirm if the problem is the hardware or retropie

[StonedEdge]

Starting to run out of ideas and thinking that it could potentially be my soldering job of the hirose connectors instead, or I've screwed something up in my schematic majorly that will call for a redesign. I really should have put test pads on the PCB so that I can easily probe things. I haven't checked the 1v8 regulator is working correctly because I can't reach it underneath the module. Is there any points I can probe on the top of the module so I don't have to probe the tiny little connectors?

to rule out your soldering and IO board, try booting a regular raspi-os image instead, that will confirm if the problem is the hardware or retropie

Hi. I tried downloading a fresh image of Raspbian but that didn't help either. I've started to work on a newer revision that integrates the nACT_LED as well as the nPWR_LED to help me with debugging for now. One thing I did notice is that the HDMI routing on my schematic is completely wrong. For some reason I haven't routed the CEC/SDA/SCL lines to the HDMI1 port (external port for connecting to a TV) and instead routed the EEPROM i2c lines for the screen we are using to the HDMI1 port as well, which may explain why I am not getting any video out.

Is there any other way I can test that the Pi boots without access to a video output source for now? My schematics are shared below. Obviously the HDMI part is ruined on this revision now, but I don't think that explains the lack of a boot (trying to ping RetroPie via cmdprmpt does not give a response). Does anyone see anything wrong with my power path? Perhaps I should add a 10nF on the soft-start pin to decrease the rise time of 5V on the regulator I am using? I also haven't added any particular SD_PWR_ON switch as recommended in the datasheet, just have the card directly powered from an external 3v3 regulator. If there's anything I am missing for a boot requirement please do let me know and I'll try and fix it up next revision!

https://drive.google.com/file/d/1E-H8lj ... sp=sharing

[dp11]

The sharing link looks broken to me. But from your last circuits why do you have an external 3.3v regulator instead of using the 3.3v from the CM4 ? what does TP22948 do? it doesn't appear to be wired to anything ?

[StonedEdge]

The sharing link looks broken to me. But from your last circuits why do you have an external 3.3v regulator instead of using the 3.3v from the CM4 ? what does TP22948 do? it doesn't appear to be wired to anything ?

Yes, that also was a screw up... 5v output should be tied to HDMI 5v pin... It's just a simple load switch that prevents HDMI 5v rail from overdrawing current in case of a short on the 5V rail. Mainly because I wasn't sure how many components I was going to use initially so I just threw on an external 3v3 regulator for now. I know the CM4 can only provide 600mA (which is plenty enough most likely...). The DVI chip we're using draws around 380mA which isn't a whole lot but I might include more components on a later revision. Sorry for the constant broken links... Try the one below

https://drive.google.com/file/d/1E-H8lj ... a2_eB/view

[StonedEdge]

The sharing link looks broken to me. But from your last circuits why do you have an external 3.3v regulator instead of using the 3.3v from the CM4 ? what does TP22948 do? it doesn't appear to be wired to anything ?

One thing I have noticed is that GLOBAL_EN is not pulled high to 5v (I'm reading 4v currently). Could that be halting boot-up? I have it connected to a floating pin on my ATtiny84 microcontroller currently (pin is undefined in software at the moment for testing).

[cleverca22]

The sharing link looks broken to me. But from your last circuits why do you have an external 3.3v regulator instead of using the 3.3v from the CM4 ? what does TP22948 do? it doesn't appear to be wired to anything ?

One thing I have noticed is that GLOBAL_EN is not pulled high to 5v (I'm reading 4v currently). Could that be halting boot-up? I have it connected to a floating pin on my ATtiny84 microcontroller currently (pin is undefined in software at the moment for testing).

does the attiny have any pulls by default?
the 2 pulls might be forming a voltage divider

try setting the attiny to also do pull-up, or neither, and see what voltage each does

if GLOBAL_EN is "low" then the 3.3v rail wont come up, which you can also measure

[StonedEdge]

The sharing link looks broken to me. But from your last circuits why do you have an external 3.3v regulator instead of using the 3.3v from the CM4 ? what does TP22948 do? it doesn't appear to be wired to anything ?

One thing I have noticed is that GLOBAL_EN is not pulled high to 5v (I'm reading 4v currently). Could that be halting boot-up? I have it connected to a floating pin on my ATtiny84 microcontroller currently (pin is undefined in software at the moment for testing).

does the attiny have any pulls by default?
the 2 pulls might be forming a voltage divider

try setting the attiny to also do pull-up, or neither, and see what voltage each does

if GLOBAL_EN is "low" then the 3.3v rail wont come up, which you can also measure

I am pretty sure that there is no default pullups. You can read the datasheet here but they need to be selected to be pulled-up.
https://ww1.microchip.com/downloads/en/ ... oc8006.pdf

3.3v rail is rising which is good news. 1v8 also rises as well!
Just to be sure - since I cannot get video out, I've been testing boot (not sure if this is the best way) by creating a file called wpa_supplicant.conf and adding the below into the file. Apparently if the Pi is booting this file will automatically be deleted from the root of the SD card. This is an adequate way to test if the Pi is booting? Obviously there are probably other better ways of doing so, but just wanted to check that I'm doing the right thing here. I'm then going onto my PC into command prompt, and typing "ping retropie"

country=jp
update_config=1
ctrl_interface=/var/run/wpa_supplicant

network={
scan_ssid=1
ssid="MyNetworkSSIDHere"
psk="InsertPasswordHere"
}

[cleverca22]

you can get far more debug if you try bringing the serial console up

Code: Select all

uart_2ndstage=1
enable_uart=1

with this, you should get some logs and maybe even a login prompt on the serial port running from gpio 14/15

[dp11]

3.3v rail is rising which is good news. 1v8 also rises as well!

That's good so you are at point 8 on the hardware checklist in the troubleshooting section.

[StonedEdge]

Hi everyone,

Another failure I believe... but I wanted to check before I order another revision of my PCB (relating to the i2c lines and master/slave devices).
On my carrier board, I have the following set-up:

1) WM8960 amp (3v3 logic) connected to the Pi on SDA0/SCL0 - currently I forgot to put any pull-up resistors on the i2c lines for this slave. Is it possible to use the 1.8k pull-ups in-built in the CM4 here for communication or do I need external pull-ups (4.7k, for example)?
2) BQ24292i charger connected to ATtiny (both pulled up to VSYS voltage of batteries w/ 4.7k resistors) - should work fine
3) MAX17055 slave (fuel gauge) connected to Pi master (pullups to VSYS voltage of batteries) - connected to the SDA1/SCL1 lines. This is where I think I've screwed up. I should be pulling the i2c lines up to the CM4_3v3 output, correct?
4) EEPROM i2c pulled up to 5v, connected to HDMI0_SCL and HDMI0_SDA on the Pi - according to the datasheet, these lines are 5v tolerant so this should be no issues here.

A point to note - VSYS voltage varies between 3.6v and 4.2v, depending on the voltage of the batteries. I think this is already outside of the tolerant range the Pi can take on its GPIO pins.

Each master and slave is on its own separate bus. I think I am mainly concerned with point 1 and 3. Could someone please confirm if I need to add external resistors on SDA0/SCL0 lines and if I need to pull-up the fuel gauge i2c to 3v3 logic?

Thanks
Ben

[aBUGSworstnightmare]

There is an 1.8k pull-up on the CM4 for GPIO3 and GPIO4 to 3.3V or 1.8V, depending on your GPIO_Vref . There are also 1.8k pull-ups on the HDMI I2C busses, to 5V on the CM4.

So, you should mention from which GPIO you wantto use the I2C.
No3 is incorrect; needs ro to pulled to GPIO_Vref.
Sorry, but how many pull-ups are in your busses? A schematic would be more helpful. And: one pull-up is enough!

[StonedEdge]

There is an 1.8k pull-up on the CM4 for GPIO3 and GPIO4 to 3.3V or 1.8V, depending on your GPIO_Vref . There are also 1.8k pull-ups on the HDMI I2C busses, to 5V on the CM4.

So, you should mention from which GPIO you wantto use the I2C.
No3 is incorrect; needs ro to pulled to GPIO_Vref.
Sorry, but how many pull-ups are in your busses? A schematic would be more helpful. And: one pull-up is enough!

Hi - thanks for your prompt response - looks like I was on the right track.
As for the pins, I've got the amplifier connected to SDA0/SCL0 (Pins 82 and Pins 80 respectively) and the fuel gauge connected to SDA1/SCL1 (Pins 58 and Pins 56 respectively). There is 3 buses, all with one single slave on them (amp, gauge, eeprom)

Currently I have no pull-ups for the amplifier (WM8960 - 3v3 logic) and I had some 4.7k pull-ups on both the HDMI0_SCL/SDA lines and 4.7k pull-ups to VSYS for the fuel gauge (mistake as mentioned earlier). Plan is to remove all of the external pull-ups and just use the internal Pi pull-ups now. Looks like there is internal pull-ups on 56, 58, 80 and 82. Is the drive strength going to be too much with a 1.8k pull-up, that's pretty strong isn't it?

[aBUGSworstnightmare]

There is an 1.8k pull-up on the CM4 for GPIO3 and GPIO4 to 3.3V or 1.8V, depending on your GPIO_Vref . There are also 1.8k pull-ups on the HDMI I2C busses, to 5V on the CM4.

So, you should mention from which GPIO you wantto use the I2C.
No3 is incorrect; needs ro to pulled to GPIO_Vref.
Sorry, but how many pull-ups are in your busses? A schematic would be more helpful. And: one pull-up is enough!

Hi - thanks for your prompt response - looks like I was on the right track.
As for the pins, I've got the amplifier connected to SDA0/SCL0 (Pins 82 and Pins 80 respectively) and the fuel gauge connected to SDA1/SCL1 (Pins 58 and Pins 56 respectively). There is 3 buses, all with one single slave on them (amp, gauge, eeprom)

Currently I have no pull-ups for the amplifier (WM8960 - 3v3 logic) and I had some 4.7k pull-ups on both the HDMI0_SCL/SDA lines and 4.7k pull-ups to VSYS for the fuel gauge (mistake as mentioned earlier). Plan is to remove all of the external pull-ups and just use the internal Pi pull-ups now. Looks like there is internal pull-ups on 56, 58, 80 and 82. Is the drive strength going to be too much with a 1.8k pull-up, that's pretty strong isn't it?

well, there are always pros and cons; CM3 had no internal pull-ups and users were failing, same. An happen with internal ones, but 1.8k should work flawlessly on 3.3V and 1.8V.
Why do you use an individual interface for each I2C slave? Is there an address conflict which can't be solved?

[StonedEdge]

Just a quick question - is the WiFi module transferable from CM4 to CM4? I ordered the wrong CM4 (non-WiFi) and have another CM4 lying around with a WiFi module (dead) that I'd like to transfer it to.