You should ythink about allowing the user to specify the port to use, especially on the Tab5, which has lots of IO ports.

Also; your (or your AI coder) seems to be confused.

pin 13 = U0TXD = G37
pin14 = U0RXD = G38

Not G3/G1

The P4 can basically mux hardware Serial onto any pin combo. And software serial can handle any pins that dont mux.

Pins G49 and G50 are on ExtPort1 on the side of the unit, (so are G0 and G1, but these should be avoided unless you understand how G0 is used at boot time).

There is a RS485 port on pins G20/G21/G34 (TX/RX/Dir) that would also be sensible to support.

And, of course, G53 and G54 on the grove connector (port-A) can be used, by default this is the User I2C bus (I2C1). If you don't want to use any external I2C peripherals then it is a good choice.

@skyflyer said in External 1S LIPO on M5Core2 BUS PIN1 and PIN30?:

I tried to find information about it, and want to confirm that it is OK to connect the external Lipo battery to pins 1 and 30 on the "BUS expansion port"? And that the battery will be charged when connected to the external USB power?

If you look at the schematic you will see that pin30 on the bus and VBAT (on the lipo connector) are the same. So yes, you can replace the internal battery with an external one with the same voltage!

@skyflyer said in External 1S LIPO on M5Core2 BUS PIN1 and PIN30?:

And I don't need to remove the internal 500mAh battery, since they would be connected in parallel anyhow?

Do not simply put rechargeable batteries in parallel. Disconnect the internal one.

• You can have batteries in parallel but.. at a minimum you need some diodes to prevent them back-charging each other, have a look online where there is a lot of info about this.

@doop4
I'm not familiar with the M5Unified driver; but I've worked with the bmi270 and written a micropython driver for it..

Despite your pillow; you will still get a bit of bounce.. (I've spent time testing this chip, it's very hard to not get any bounce when you do this sort of test.)

But, I think you are seeing the device going out of range; at which point you get weird/invalid readings.

I dont see anywhere in your code setting the acceleration range; the max is +/- 16G, but it defaults to +/- 8g, which is where your readings appear to fail. I guess M5Unified has a method for setting this? Try the biggest range.

Also; you can set filtering based on an average mode; the default is to average 4 readings (the sensor runs at 20MHz) but this can be set all the way up to 128.

The M5Unified driver is using 'direct readings' (just like my driver), do not confuse this with 'FIFO' mode; which is an automated, IRQ triggered high-speed burst capture method. You read the dataset out from the chip buffer after the event has ended. AFIK the M5 drivers do not support this.

I've just finished work on a full feature micropythin driver for this Real Time Controller chip fitted to the Tab5 (and other M5 products etc.)

https://codeberg.org/easytarget/rx8130ce-micropython

As an example;

# Create a I2C object
# set sda/scl as needed, example below for esp32p4

from machine import I2C, Pin
i2c = I2C(sda = Pin(31), scl = Pin(32))

# Create a clock object
from rx8130ce import RX8130
clock = RX8130(i2c)

print(clock.timestring())

# demo of timer
from time import sleep

# set a timer for 10s at 64Hz countdown
clock.timer_enable(count = 640, tsel = 1)

# wait for the timer
while not clock.timer_interrupt():
  sleep(0.1)
  print('.', end='')
print('\nTimeout: ', clock.timestring())

# disable timer
clock.timer_enable(0)

This gives:

MPY: soft reboot
MicroPython v1.27.0 on 2025-12-09; Generic ESP32P4 module with WIFI module of external ESP32C6 with ESP32P4
Type "help()" for more information.
>>> import test.py
Fri, 30 Jan 46, 17:16:06
....................................................................................................
Timeout:  Fri, 30 Jan 46, 17:16:16
>>> 

There is a lot more in the repo, including a demo of how to use the RTC to set the system clock at boot time.

All the chip 'advanced' features can be accessed via the driver, but are of limited value on the Tab5 due to not having some pins connected, and the /IRQ pin being rendered almost useless by the power management mcu.

Like @felmue I also did a bit more testing of the low voltage flags, then enabled the charge circuit (and setting the charge voltage via bfvsel to unlimited). The clock has held time ever since.

I'm curious about how long the capacitor can run the clock when fully charged and I have disabled charging again. But my device spends most of it's time on USB power so the duration is hard to measure; so lets try to estimate it :-)

If the frequency out and I2C is disabled (inien = True) the device should typically draw 0.3 µA when on backup battery (table 5 in the datasheet).
The capacitor is possibly a ML414H; 0.07 F.
Table 3 in the datasheet says that the clock oscillator minimum voltage is 1.1v, and the start voltage is VStandby; 3.3v. So we just need to work out the discharge time.

Start with working out the equivalent resistance at 3.3v; R=Voltage/Current = 3.3/0.0000003 = 11000000 = 11 MΩ

Now use an online discharge calculator to do the 'heavy lifting'...
https://3roam.com/capacitor-discharge-time-calculator/
(I like that site; it shows the maths used)

This gives an estimated! time of 845932 seconds; which is ~235 hours, almost ten days. Which seems reasonable for a capacitor backup.

@felmue said in Tab5 RTC backup battery specifications:

RTC supercapacitor

Once again, thankyou, :-) I am getting cynical, it never occurred to me to just check the specs. doh!

It's a supercapacitor, which explains what I'm seeing. the chip loses time if power is off (fully off, no main battery or usb power) for more than a few minutes. I was hoping that is because it is a supercapacitor and needs a charge, but reluctant to turn charge on if it was just a dud silverNickel cell.

For context: I'm writing a micropython driver for this chip and testing / debugging on my Tab5. I need to go to the datasheet and work out the correct bits to set in my driver. That link to the M5Unified library is really appreciated too!

@sam_20 :
The rx8130ce has built-in fault detection for the backup battery. So it makes sense for M5 to enable it in the M5Unified init() routines. I will be working out (or just copying..) the correct settings myself and setting up my boot.py to enable 'charge' for this as well as the main battery at boot. My driver is generic, it will support all of the 8130's power modes and flags. It will default to charge off because that is safest.

I'm wondering if anybody can answer this; the Tab5 has a RTC chip with a dedicated backup battery on the PCB:

Does anybody have electrical specs for this part? or a part number? It would be really handy to have this info.

• The rx8310 RTC chip has a number of settings for controlling and monitoring it's backup battery, it can charge rechargeable ones (for instance) and has configurable switching levels.
• You need to know what type/capacity of battery you are working with to set this up correctly. The defauls are for a simple non-rechargable cell. Is this what the Tab5 has?

@michael-koppelman
Maybe It's a form of watchdog that guards against the device powering on and then pointlessly flattening the battery while doing nothing because there is no code running. It protects the battery against wasted charge-cycles.
Or maybe it's just a 'feature' of the power control circuit. ;-)

@007jimmey
A bit late to the party here but.. maybe of help to you or others

The bmp280 temperature/humidity/pressure sensor is well known, there are lots of libraries for this (I2C) eg: https://github.com/robert-hh/BME280

• it has it's own I2C address and is separate from the bmi270/bmm150

The bmi270 six axis sensor (acceleration and gyro) has a basic, large and slow driver here: https://github.com/micropython/micropython-lib/tree/master/micropython/drivers/imu/bmi270

I have my own pair of drivers for this:
https://codeberg.org/easytarget/bmi270-micropython

• bmi270_fast.py is a drop-in replacement for the above driver, but is 5x smaller, and 25x faster loading. (92 ms vs 2.3 seconds..)
• bmi270_legacy.py is a work in progress full-feature driver I'm working on for my Tab5. It uses for the 'legacy config' (tablet/mobile phone featureset) and has motion and orientation sensors and interrupts available.

But.. the BMM150 magnetometer is an issue, it is attached to the 'auxillary' bus of the BMI270, not to the main I2C bus. You can only to access it via special features in the BMI270, and none of the MicroPython drivers support it.

@felmue
Thank you! you are quite right! I hadn't really looked at what was happening properly :-(

The pin needs to be toggled high then low with a ~50ms delay for a full power off, just toggling it high does a full reset (after 1 second). I really wish there was a state diagram (or similar) available for the code in the PMS150G power control MCU.

I've extended my code to do the required pulse similar to your modification, and added a reset_device() method too. Plus relevant notes in the README etc, and done a new release.

[testing shows that the poweroff happens immediately after the first pulse, I'm not sure why they attempt to pulse several times but I guess they are just making sure.. ;-)]

Hi all;

This is something I've been working on; a easy way of taking control of the Tab5's power management circuitry from vanilla MicroPython; without needing a special board build.

https://codeberg.org/easytarget/tab5-egpio-micropython

The README there has the full install and usage notes; plus a list of the (30!) methods it provides. This is deigned to be very simple in use; it is self-contained and lets you:

• Control power on/off for the WiFi chip, Speaker Amplifier, USB-A port and Expansion port 5V power.
• Switch WiFi between internal and external antennas
• Enable and disable battery charging, set the quick charge status, read the charge indicator pin.
• Read the battery voltage and current in/out.
• Detect if headphones are plugged in.
• Set LCD backlight brightness
• Trigger a poweroff event.
• Send reset signals to the LCD, TouchPanel and Camera modules.

Use it to create a power control object and set the device up as you need:

from tab5_egpio import TAB5_EGPIO

tab5pwr = TAB5_EGPIO()
tab5pwr.wlan_pwr_on()
tab5pwr.charge_enable()

# later (let the charge controller settle first)
voltage, current = tab5pwr.battery_status()
print('Battery: {:.2f}V @ {:.3f}A'.format(voltage, current))

There are some demo's in the repo that show how to use this in more detail. And I have a page where I am documenting general hardware related Tab5 micropython information at: https://codeberg.org/easytarget/m5-tab5-micropython

[note: I'm cross-posting this here from the micropython official discussions, since it is specific to the Tab5]

@felmue Thank you for doing the test :-)

I guess this simplifies things for anybody writing a driver; but does prevent people having fun-and-games with under/over clocking the camera module.

I think it also means you cannot 'stop' the camera, which may be problem for extreme power saving. But I suspect the reset pin can be used to halt the module too.

@konstantint Thankyou for doing that! very useful.

I see your config puts the reset pin definitions directly in the correct driver sections for the touchscreen and LCD so that those driver handle them correctly. I think this is better than doing it separately the way I suggested :-)

@manmade
I dont see the nRESET signal being removed from the LCD, TouchPanel (and Camera).
It's a low=active reset for these devices, and the E1 pi4ioe5v6408 chip that controls them will default these pins to low (actually, input-pulldown) and holds the reset pin active. These are pins 4,5,6 on the chip:

Maybe you need something like:

  - platform: gpio
    id: lcd_nreset
    name: "LCD nRESET"
    pin:
      pi4ioe5v6408: pi4ioe1
      number: 4
    restore_mode: ALWAYS_ON

  - platform: gpio
    id: tp_nreset
    name: "TP nRESET"
    pin:
      pi4ioe5v6408: pi4ioe1
      number: 5
    restore_mode: ALWAYS_ON

  - platform: gpio
    id: cam_nreset
    name: "CAM nRESET"
    pin:
      pi4ioe5v6408: pi4ioe1
      number: 6
    restore_mode: ALWAYS_ON

Because these are active-low lines they are being applied when the unit powers up, you have to explicitly remove them after boot.

This is a guess, I'm not running HA on my tab5. There may be other things that need to happen too or are broken. But I just spent all day playing with some TAB5 hardware stuff in MicroPython and
this was one of the things I discovered..

Hi. I've been looking at the Tab5 Schematics a lot recently. And noticed something that appears 'wrong'.

In the block diagrams the camera modules CAM_MCLK line is shown as coming from pin G36 of the esp32-p4.

But the schematic tells a different story;

On the ESP32-P4 we have CAM_MCLK_GPIO36 coming from the esp32-p4:

It has a 10K pullup (R10) to SOC_3.3V:

But then is not used!

There are two N/C (Not Connected) resistors (R27 & R109) on the connection to U35 (which drives the camera modules CAM_MCLK_1V8 at 1.8v)

But note that the connection shown as PXT24M is connected, and comes from X2, a 24 MHz CMOS crystal oscillator.

Which is correct? The Schematic or the block diagrams?

If setting up a camera driver on the Tab5 can we safely ignore setting up gpio36 and just assume the camera MCLK is permanently fixed at 24MHz?

Edit: This isnt a criticism, it's quite normal; The board was designed so that it can accommodate two different camera module units. And the decision about which one to use can then be made closer to production time. Circuit designers do this a lot; the appropriate components are added/removed at production time without the PCB layout needing to be changed.

@HappyUser The Tab5 also has a M-BUS interface (the big 30pin socket on the back) and mounting points for the m-bus modules.

So; in theory you can 'just' plug in one of the modules from here: https://docs.m5stack.com/en/products?id=for stack-module

But in practice it will probably need a bunch of work and understanding to get the pin assignments and drivers on the tab5 aligned and working.

• There are other interesting M-BUS modules available (GPS, motor drive, prototype board, etc..)
• The tab5 has the correct threaded mounting points to make the boards secure etc.

@milaidin :
Poking around in the schematic shows that the Audio jack has a switch pin connected to a line labelled HP_DET on the board. As far as I can tell this line is pulled low via R47&R48 unless there is a plug inserted. when it is pulled high via R49 instead.
This HP_DET line does not go directly to the P4 chip, instead it goes to U6, which is a I2C I/O expander chip on the system I2C bus.

If the source for the demo is available look for how this line is read, then turn the amplifier on/off as needed. The code for that should also be in the demo.

Hi @MortenComadan ; you don't mention what your project is based on for code; Arduino/ESP-IDF/MicroPython/UFlow2 etc..

For the tools where Expressif have got involved the support should be there already. The C6 co-processor gets a standard firmware (that talks via QSPI to the P4) and the P4 IDF libraries know how to use this.

• What I'm unsure about is exactly which features are actually implemented in the ESP IDF; I want to use bluetooth audio sink features.. eventually.

If (like me) you are into MicroPython then good news. V1.27.0 was released a couple of days ago and has official P4 support: https://github.com/micropython/micropython/releases/tag/v1.27.0

UFlow2 is based on an older micropython version; I'm not sure how much of the P4 stuff they may have backported.

I only got my Tab5 today, I'm going to be installing micropython 1.27 asap.