Core 2 and COMMU
Camier last edited by
@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 ;-).
mikeljo last edited by
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!!!
TLS last edited by
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).
ray3 last edited by
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.
TLS last edited by
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.
felmue last edited by
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.
felmue last edited by
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.