<![CDATA[Topics tagged with cores3]]>https://community.m5stack.com/tags/cores3RSS for NodeMon, 16 Mar 2026 20:56:17 GMTInvalid Date60<![CDATA[Issue with unit 4 relay on cores3]]>On the cores3 (module connected through port A), I see no devices found on i2c scan when using esphome. It finds OK on the atom-lite.
If using the "Cores3 test" binary from m5stack, I can see the address found on the i2c scan app.

]]>https://community.m5stack.com/topic/8126/issue-with-unit-4-relay-on-cores3https://community.m5stack.com/topic/8126/issue-with-unit-4-relay-on-cores3Invalid Date<![CDATA[CoreS3 read data via usb_uart]]>Hello. I’m trying to read data via usb_uart on an M5Stack CoreS3 from a CDC-ACM device, without success.
Here some config entries.
I moved the logger to a different interface. I have no idea whether this is necessary, but this way it definitely doesn’t occupy the USB interface.

logger:
  baud_rate: 0
  hardware_uart: UART0
  level: VERBOSE
  initial_level: DEBUG
  logs: 
    usb_uart: VERBOSE
    usb_host: VERBOSE
    uart_debug: VERBOSE

Outputs

output:
  - platform: axp2101
    type: range
    channel: DLDO1
    id: lcd_backlight_output
    min_voltage: 2600
    max_voltage: 3300

  - platform: axp2101
    channel: ALDO1
    voltage: 1800

  - platform: axp2101
    channel: ALDO2
    voltage: 3300
  
  - platform: axp2101
    channel: BLDO1
    voltage: 2800
  
  - platform: axp2101
    channel: BLDO2
    voltage: 1500

Then I set these switches:

switch:
  - platform: gpio
    name: "bus_out_en_sw"
    internal: true
    pin:
      aw9523b: aw9523b_hub
      number: 1
    restore_mode: ALWAYS_ON

  - platform: gpio
    name: "usb_otg_en_sw"
    internal: true
    pin:
      aw9523b: aw9523b_hub
      number: 5
    restore_mode: ALWAYS_ON

  - platform: gpio
    name: "boost_en_sw"
    internal: true
    pin:
      aw9523b: aw9523b_hub
      number: 15
    restore_mode: ALWAYS_ON

  - platform: gpio
    name: "AW RST P0_2"
    internal: true
    pin:
      aw9523b: aw9523b_hub
      number: 2
    restore_mode: ALWAYS_ON

And configure the usb_uart

usb_uart:  
  - type: cdc_acm
    id: scanner_bus
    vid: 0x152A
    pid: 0x880F
    channels:
      - id: uch_1
        debug: true

The device is a barcode scanner Digitus DA-8002
DC 3.3 - 5V, 120 mA, idle 1uA
The scanner is set as "USB serial interface output".
Adapter USB-C to USB-A Greencell 2.4A 480 Mbps
Power supply CoreS3: Yingjiao YS35V-1203000, 12V, 3A, 36W
Baudrate scanner: 9600
The scanner is powered. When I plug it in, it beeps, and it also beeps when I scan.
It has a USB-A interface, and I’m using a USB-C to USB-A OTG adapter.
The scanner works without any problem with this exact adapter on a Windows PC and on an Android smartphone.
This is the log when I plug in the scanner.

[18:14:15.614][D][usb_host:265]: Open device 1
[18:14:15.615][D][usb_host:272]: Get descriptor device 1
[18:14:15.615][D][usb_host:279]: Device descriptor: vid 152A pid 880F
[18:14:15.616][D][usb_host:289]: Device connected: Manuf: MINJCODE; Prod: MINJCODE MJ2818A; Serial: 00000000050C
[18:14:15.618][V][usb_host:089]: *** Device descriptor ***
[18:14:15.618]bLength 18
[18:14:15.618]bDescriptorType 1
[18:14:15.618]bcdUSB 1.10
[18:14:15.618]bDeviceClass 0x2
[18:14:15.618]bDeviceSubClass 0x0
[18:14:15.618]bDeviceProtocol 0x0
[18:14:15.618]bMaxPacketSize0 64
[18:14:15.618]idVendor 0x152a
[18:14:15.618]idProduct 0x880f
[18:14:15.618]bcdDevice 1.00
[18:14:15.618]iManufacturer 1
[18:14:15.618]iProduct 2
[18:14:15.618]iSerialNumber 3
[18:14:15.618]bNumConfigurations 1
[18:14:15.627][V][usb_host:070]: *** Configuration descriptor ***
[18:14:15.627]bLength 9
[18:14:15.627]bDescriptorType 2
[18:14:15.627]wTotalLength 67
[18:14:15.627]bNumInterfaces 2
[18:14:15.627]bConfigurationValue 1
[18:14:15.627]iConfiguration 0
[18:14:15.627]bmAttributes 0x80
[18:14:15.627]bMaxPower 500mA
[18:14:15.652][V][usb_host:056]: 	*** Interface descriptor ***
[18:14:15.652][V][usb_host:056]: 	bLength 9
[18:14:15.652][V][usb_host:056]: 	bDescriptorType 4
[18:14:15.652][V][usb_host:056]: 	bInterfaceNumber 0
[18:14:15.652][V][usb_host:056]: 	bAlternateSetting 0
[18:14:15.652][V][usb_host:056]: 	bNumEndpoints 1
[18:14:15.652][V][usb_host:056]: 	bInterfaceClass 0x2
[18:14:15.652][V][usb_host:056]: 	iInterface 0
[18:14:15.669][V][usb_host:042]: 		*** Endpoint descriptor ***
[18:14:15.669][V][usb_host:042]: 		bLength 7
[18:14:15.669][V][usb_host:042]: 		bDescriptorType 5
[18:14:15.669][V][usb_host:042]: 		bEndpointAddress 0x82	EP 2 IN
[18:14:15.669][V][usb_host:042]: 		bmAttributes 0x3	INT
[18:14:15.669][V][usb_host:042]: 		wMaxPacketSize 8
[18:14:15.669][V][usb_host:042]: 		bInterval 10
[18:14:15.679][V][usb_host:056]: 	*** Interface descriptor ***
[18:14:15.679][V][usb_host:056]: 	bLength 9
[18:14:15.679][V][usb_host:056]: 	bDescriptorType 4
[18:14:15.679][V][usb_host:056]: 	bInterfaceNumber 1
[18:14:15.679][V][usb_host:056]: 	bAlternateSetting 0
[18:14:15.679][V][usb_host:056]: 	bNumEndpoints 2
[18:14:15.679][V][usb_host:056]: 	bInterfaceClass 0xa
[18:14:15.679][V][usb_host:056]: 	iInterface 0
[18:14:15.692][V][usb_host:042]: 		*** Endpoint descriptor ***
[18:14:15.692][V][usb_host:042]: 		bLength 7
[18:14:15.692][V][usb_host:042]: 		bDescriptorType 5
[18:14:15.692][V][usb_host:042]: 		bEndpointAddress 0x1	EP 1 OUT
[18:14:15.692][V][usb_host:042]: 		bmAttributes 0x2	BULK
[18:14:15.692][V][usb_host:042]: 		wMaxPacketSize 64
[18:14:15.692][V][usb_host:042]: 		bInterval 0
[18:14:15.699][V][usb_host:042]: 		*** Endpoint descriptor ***
[18:14:15.699][V][usb_host:042]: 		bLength 7
[18:14:15.699][V][usb_host:042]: 		bDescriptorType 5
[18:14:15.699][V][usb_host:042]: 		bEndpointAddress 0x81	EP 1 IN
[18:14:15.699][V][usb_host:042]: 		bmAttributes 0x2	BULK
[18:14:15.699][V][usb_host:042]: 		wMaxPacketSize 64
[18:14:15.699][V][usb_host:042]: 		bInterval 0
[18:14:15.719][D][usb_host:304]: Call on_connected
[18:14:15.721][D][usb_uart:331]: device connected
[18:14:15.730][D][usb_uart:031]: intf_desc: bInterfaceClass=02, bInterfaceSubClass=02, bInterfaceProtocol=01, bNumEndpoints=1
[18:14:15.740][D][usb_uart:041]: ep: bEndpointAddress=82, bmAttributes=03
[18:14:15.750][D][usb_uart:031]: intf_desc: bInterfaceClass=0A, bInterfaceSubClass=00, bInterfaceProtocol=00, bNumEndpoints=2
[18:14:15.760][D][usb_uart:041]: ep: bEndpointAddress=01, bmAttributes=02
[18:14:15.771][D][usb_uart:041]: ep: bEndpointAddress=81, bmAttributes=02
[18:14:15.771][V][usb_uart:081]: Found CDC-ACM device
[18:14:15.781][D][usb_uart:338]: Found 1 CDC-ACM devices
[18:14:15.783][D][usb_uart:390]: enter enable_channels
[18:14:15.791][D][usb_uart:398]: start_input for channel
[18:14:15.793][D][usb_uart:278]: call transfer_in epAddress: 0x81, MaxPacketSize: 64
[18:14:15.802][D][usb_uart:283]: transfer_in returns true
[18:14:15.802][W][component:547]: usb_host took a long time for an operation (189 ms)
[18:14:15.812][W][component:550]: Components should block for at most 30 ms
[18:14:15.826][D][usb_host:174][usb_task]: New device 1

As it looks, the transfer is submitted with usb_host_transfer_submit. There are absolutely no error messages and everything looks correct. The callback is just never called—no matter what, how much, or how fast I scan.

What did I forget? Is this even possible at all?

]]>https://community.m5stack.com/topic/8078/cores3-read-data-via-usb_uarthttps://community.m5stack.com/topic/8078/cores3-read-data-via-usb_uartInvalid Date<![CDATA[Demo Sketches for Module USB V1.2 do not compile or link]]>I am experiencing an issue with a Module USB V1.2 I just purchased. None of the example Sketches compile. I would like to try the module out on a CoreS3.

The first issue was a missing header file "M5_Max3421E_Usb.h". I did not find any library through the Library Manager in the Arduino IDE, so I downloaded the M5-Max3421E-USBShield library ZIP file from github and installed it that way.

This allowed the USB mouse example Sketch to compile, but it fails to link due to duplicate symbols, like tuh_init, that already exist in the arduino_tinyusb.a library.

If I take arduino_tinyusb.a out of the platform.txt file, for the CoreS3, I still have a few tuh_ symbols missing as well as a __atomic_test_and_set symbol missing. I don't see any atomic library anywhere.

If I take steps to remove conflicts from the M5-Max3421E-USBShield library, I am still left with the missing _atomic_test_and_set symbols. I am not sure if changing the library is correct as I don't know if there is a version conflict between all the tuh functions in the M5-Max3421E-USBShield library and arduino_tinyusb.

Does anyone have any advice on correcting this issue?

I would really like to use the mass storage capability of the module, so any recent links for M5Stack projects that successfully use the module would be helpful.

]]>https://community.m5stack.com/topic/7808/demo-sketches-for-module-usb-v1-2-do-not-compile-or-linkhttps://community.m5stack.com/topic/7808/demo-sketches-for-module-usb-v1-2-do-not-compile-or-linkInvalid Date<![CDATA[CoreS3 and unit CatM GNSS cannot cooperate]]>Felix @felmue OMG, this was so easy...many thanks, that was the reason why the unit wasn't reacting for any commands. Have a nice day

]]>https://community.m5stack.com/topic/6282/cores3-and-unit-catm-gnss-cannot-cooperatehttps://community.m5stack.com/topic/6282/cores3-and-unit-catm-gnss-cannot-cooperateInvalid Date<![CDATA[M5 CoreS3 power drain issue.]]>I recall the last action before I started to have the issue and I now suspect it was my particular scenario of charging the din base battery that might have damaged one or more of the power distribution mosfets. I shall describe the scenario here as a caution for fellow core s3 owners.

firmware installed: uiflow 2.0.1
external device connected: M5Stack GPS/BDS unit connected to port c at the din base.
charger used: wall charger with multiple usb c and a ports. one of the usb c port was used.
sequence of event:

a gps related uiflow program was running and the battery dropped low connected the wall charger to the core s3 with a usb c to c cable to charge the battery inside the din base after some time switched off the core s3 by holding the power button while the charging is still going on core s3 felt very warm to the touch but I did not think too much of it. charging was completed after the red indicator turned off

I suspected that in sequence 4 one or more mosfets were overheated and damaged.

]]>https://community.m5stack.com/topic/6196/m5-cores3-power-drain-issuehttps://community.m5stack.com/topic/6196/m5-cores3-power-drain-issueInvalid Date