Core 2 and COMMU

  • @felmue - UART2 has moved, really? the "current" espressif module data sheet in the download section of the current M5 Stack (Core 2) products still indicate GPIO 16 & 17. I feel a rabbit hole in the making....

    In general, I would like at least 2 UART Rx channels. The M5 Stack comes with 3x UARTS according to the spec sheet.

    From another internet source on the subject of UART and ESP32, I found the following:

    • U0UXD is used to communicate with the ESP32 for programming and during reset/boot.
    • U1UXD is unused and can be used for your projects. Some boards use this port for SPI Flash access though
    • U2UXD is unused and can be used for your projects.

    So, I thought, easy-peasy....I can count on being able to use UART1 and 2 - the M5 Stack (Core2) should be able to manage this, correct?
    (I don't plan attaching any GPS-Module, etc, so....2x UARTs should be the minimum available)

    But your having mentioned that the pin layout is different makes we question how reliable the M5 documentation really is (?).

    Appreciate any feedback...also bookmarked your pinning page, thanks.

  • Hello @Camier

    the GPIO information regarding M5Core2 UART2 is correct here - check section M5Core2 M-BUS Schematic diagram and Section M5Core2 BUS(compared to M5Stack). M5Stack even has linked my comparison sheet. Yay!

    Where exactly did you find the incorrect information? Never mind - found it. The GPIO list in the Espressif document you mentioned shows each pin and its possible (default) functionality. Luckily though ESP32 has a GPIO Matrix which allows to reassign almost any pin to any function. Unfortunately GPIO16 / GPIO17 are required for PSRAM and therefore M5Stack was forced to assign two other GPIOs for UART2.

    BTW: GPIO7, GPIO8, GPIO9, GPIO10, GPIO16, GPIO17 are used for PSRAM.


  • @felmue appreciate the quick response and link - will have to wrap my head around the specific info to the Core2 configuration. I'll try my best to decipher it but don't be surprised if I come back with my tail between my legs and a few questions ;-).

  • And how do you fix that you can not burn/flash the Core2 when the COMMU is installed?
    I have the same Problem. Can not flash Core2 when Commu is connected.
    Commu works at my Core, Fire and Core2.
    Flash works when Commu is installed at Core and Fire, but NOT on Core2. There i must remove COMMU to flash!!!

  • I encountered this same problem, the COMMU module works, but I cannot upload a sketch without detatching it first. I don't see the pin conflict with the core-2. Anyone found a solution? I'm not using the uart, only the CAN(SPI) and RS485 (Serial2).

  • I just acquired the Core 2 and COMMU unit.

    I need the CAN bus, but can't seem to get it to work.

    What pins did you find work for this device in order to access the CAN bus?

    Note, I also have the CAN I2C module that I am also trying to use, but can't get it to work either.

  • Hi, about the problem not being able to upload a sketch when the commu is attached to the core2; I found the culprit: it's gpio2-pin (core2) to the M5-bus pin 15, which is the INT-output of the MCP2515-chip. Pin 2 of the ESP is a strapping pin which needs to be low when uploading a sketch, while the MCP-chip pulls it to high-level. A dirty fix is to wire-wrap the pin2 to a button that can ground the pin during sketch-upload.

  • @tls thank you for that! I had the same problem and had a ticket open with the very nice but otherwise clueless M5 support team, who ended up sending me a 2nd COMMU module, which - of course - also didn't work.
    Just to be 100% sure that I understand what you write here:
    When you write "Pin 2 of the ESP is a strapping pin", that would be the "EN" or "RESET" pin, which is Pin 2 on some ESP32 DEV boards and Pin 15 on some others - correct? On the Core2 M-BUS it would be the Pin labeled "RST" or "EN" (3rd from the top in the right row).
    I'm assuming that the old trick with the 22 uF condensator between "EN" and GND wouldn't work here, because the MCP chip immediately pulls it high?

  • @chriszang quick update: I just gave it a try: I soldered a wire to the "EN" pin and grounded it for a moment as soon as the ....... started to show when upload starts.. Never got it to work, getting basically the same error message as before. Bummer.

  • Hello @ChrisZang

    no, not EN, but pin 15 on the M-Bus (which on M5Core2 is pin 2). Please also see the COMMU schematic here. Pin 15 is labelled CAN_INT.


  • @felmue Thanks, gotcha (at least I think I gotacha ;-). So if i scroll down further on your link to "MBUS PinMap" it would be the pin labeled "IISOUT" ?

  • @felmue Yes, thanks that was it :-)
    So basically you compile & upload your sketch, you wait until the "...." appears, you press the button and then the upload works.
    Thanks again.

  • Hello @ChrisZang

    glad to hear you got it working.

    @TLS : thank you for figuring out the issue and letting us know.


  • @chriszang and one more thing that I just learned:
    The GPIO for the CS Pin for the mcp2515 is 27 (not 12 as the documentation says).
    If you want to initialize the mcp2515 in the COMMU do this:

    MCP2515 CAN0(27); // (mcp2515 library)
    MCP_CAN CAN0(27); // (mcp_can library)

  • @chriszang and another update.
    So I am happily working on my CAN receiver sketch and just noticed that I forgot to press the button that grounds INT-output of the mc2515 but the upload still worked. Gave it another try (w/o pressing the button) and it's still working - weird.
    Then I swapped this COMMU module for my 2nd COMMU Module and here the upload doesn't work.
    My explanation is that the grounding of the mcp2515 INT-output basically created a short circuit in the transistor that controls this pin and eventually burned it out. Not a big problem for me as
    a) I am not using interrupts in my sketch
    b) I have a 2nd COMMU unit
    I just wanted to warn you guys that grounding the INT output has unintended consequences.