A year ago?

It looks to me like you have a duff RGB panel. Did you ever get it swapped?

Thank you both!

In the interests of experimentation... I just had to see what havoc using the Grove connector with the IR Unit would cause.

I found that if I don't actively access the IC2 components, and just treat them as standard IO pins, they don't get in the way of any data I'm getting.

I was able to demonstrate this really well with the IR Remote Control demo, using one Grove pin for the IR receiver, and turning the other Grove pin low to turn off the IR LED (which gets in the way of reception).

I was able to scan 3 different remote controls, and also produce their raw flashes on the LCD as a diagram!

For anyone that wants/needs to do this very un-recommended Grove useage:

/*
   IRremoteESP8266: IRrecvDumpV3 - dump details of IR codes with IRrecv
   An IR detector/demodulator must be connected to the input kRecvPin.

   Copyright 2009 Ken Shirriff, http://arcfn.com
   Copyright 2017-2019 David Conran

   Example circuit diagram:
	https://github.com/crankyoldgit/IRremoteESP8266/wiki#ir-receiving

   Changes:
	 Version 1.2 October, 2020
	   - Enable easy setting of the decoding tolerance value.
	 Version 1.1 May, 2020
	   - Create DumpV3 from DumpV2
	   - Add OTA Base
	 Version 1.0 October, 2019
	   - Internationalisation (i18n) support.
	   - Stop displaying the legacy raw timing info.
	 Version 0.5 June, 2019
	   - Move A/C description to IRac.cpp.
	 Version 0.4 July, 2018
	   - Minor improvements and more A/C unit support.
	 Version 0.3 November, 2017
	   - Support for A/C decoding for some protocols.
	 Version 0.2 April, 2017
	   - Decode from a copy of the data so we can start capturing faster thus
		 reduce the likelihood of miscaptures.
   Based on Ken Shirriff's IrsendDemo Version 0.1 July, 2009,
*/

// Allow over air update
// #define OTA_ENABLE true
//#include "BaseOTA.h"

#include <M5Stack.h>

//#include <Arduino.h>
#include <assert.h>
#include <IRrecv.h>
#include <IRremoteESP8266.h>
#include <IRac.h>
#include <IRtext.h>
#include <IRutils.h>

// M5Stack Core grey screen dimensions, and settings for the diagram display.
int dispWidth = 320;
int dispHeight = 240;
int stripNum = 0;
int stripsDownScreen = 6;
int stripHeight = dispHeight / stripsDownScreen;


// ==================== start of TUNEABLE PARAMETERS ====================
// An IR detector/demodulator is connected to GPIO pin 14
// e.g. D5 on a NodeMCU board.
// Note: GPIO 16 won't work on the ESP8266 as it does not have interrupts.
const uint16_t kRecvPin = 22; // Pin 22 on the M5Stack-Core-Grey.

// The Serial connection baud rate.
// i.e. Status message will be sent to the PC at this baud rate.
// Try to avoid slow speeds like 9600, as you will miss messages and
// cause other problems. 115200 (or faster) is recommended.
// NOTE: Make sure you set your Serial Monitor to the same speed.
const uint32_t kBaudRate = 115200;

// As this program is a special purpose capture/decoder, let us use a larger
// than normal buffer so we can handle Air Conditioner remote codes.
const uint16_t kCaptureBufferSize = 2048;

// kTimeout is the Nr. of milli-Seconds of no-more-data before we consider a
// message ended.
// This parameter is an interesting trade-off. The longer the timeout, the more
// complex a message it can capture. e.g. Some device protocols will send
// multiple message packets in quick succession, like Air Conditioner remotes.
// Air Coniditioner protocols often have a considerable gap (20-40+ms) between
// packets.
// The downside of a large timeout value is a lot of less complex protocols
// send multiple messages when the remote's button is held down. The gap between
// them is often also around 20+ms. This can result in the raw data be 2-3+
// times larger than needed as it has captured 2-3+ messages in a single
// capture. Setting a low timeout value can resolve this.
// So, choosing the best kTimeout value for your use particular case is
// quite nuanced. Good luck and happy hunting.
// NOTE: Don't exceed kMaxTimeoutMs. Typically 130ms.

/*
#if DECODE_AC
// Some A/C units have gaps in their protocols of ~40ms. e.g. Kelvinator
// A value this large may swallow repeats of some protocols
const uint8_t kTimeout = 50; //50
#else   // DECODE_AC
// Suits most messages, while not swallowing many repeats.
const uint8_t kTimeout = 15; //15
#endif  // DECODE_AC
*/
const uint8_t kTimeout = 50;

// Alternatives:
// const uint8_t kTimeout = 90;
// Suits messages with big gaps like XMP-1 & some aircon units, but can
// accidentally swallow repeated messages in the rawData[] output.
//
// const uint8_t kTimeout = kMaxTimeoutMs;
// This will set it to our currently allowed maximum.
// Values this high are problematic because it is roughly the typical boundary
// where most messages repeat.
// e.g. It will stop decoding a message and start sending it to serial at
//      precisely the time when the next message is likely to be transmitted,
//      and may miss it.

// Set the smallest sized "UNKNOWN" message packets we actually care about.
// This value helps reduce the false-positive detection rate of IR background
// noise as real messages. The chances of background IR noise getting detected
// as a message increases with the length of the kTimeout value. (See above)
// The downside of setting this message too large is you can miss some valid
// short messages for protocols that this library doesn't yet decode.
//
// Set higher if you get lots of random short UNKNOWN messages when nothing
// should be sending a message.
// Set lower if you are sure your setup is working, but it doesn't see messages
// from your device. (e.g. Other IR remotes work.)
// NOTE: Set this value very high to effectively turn off UNKNOWN detection.
const uint16_t kMinUnknownSize = 12;

// How much percentage lee way do we give to incoming signals in order to match
// it?
// e.g. +/- 25% (default) to an expected value of 500 would mean matching a
//      value between 375 & 625 inclusive.
// Note: Default is 25(%). Going to a value >= 50(%) will cause some protocols
//       to no longer match correctly. In normal situations you probably do not
//       need to adjust this value. Typically that's when the library detects
//       your remote's message some of the time, but not all of the time.
const uint8_t kTolerancePercentage = kTolerance;  // kTolerance is normally 25%

// Legacy (No longer supported!)
//
// Change to `true` if you miss/need the old "Raw Timing[]" display.
#define LEGACY_TIMING_INFO false
// ==================== end of TUNEABLE PARAMETERS ====================

// Use turn on the save buffer feature for more complete capture coverage.
IRrecv irrecv(kRecvPin, kCaptureBufferSize, kTimeout, true);
decode_results results;  // Somewhere to store the results

// This section of code runs only once at start-up.
void setup() {
  // Setup the M5Core systems, and ready the screen.
  M5.begin();
  M5.Power.begin();
  M5.Lcd.fillScreen(WHITE);
  M5.Lcd.setTextColor(WHITE);
  M5.Lcd.setTextSize(1);
  M5.Lcd.setCursor(10, 10);

  // Turn off the IR LED - otherwise it makes noise for the receiver.
  pinMode(21, OUTPUT);
  digitalWrite(21, LOW);

  delay(100);

  //OTAwifi();  // start default wifi (previously saved on the ESP) for OTA
#if defined(ESP8266)
  Serial.begin(kBaudRate, SERIAL_8N1, SERIAL_TX_ONLY);
#else  // ESP8266
  Serial.begin(kBaudRate, SERIAL_8N1);
#endif  // ESP8266
  while (!Serial)  // Wait for the serial connection to be establised.
	delay(50);
  // Perform a low level sanity checks that the compiler performs bit field
  // packing as we expect and Endianness is as we expect.
  assert(irutils::lowLevelSanityCheck() == 0);

  Serial.printf("\n" D_STR_IRRECVDUMP_STARTUP "\n", kRecvPin);
  //OTAinit();  // setup OTA handlers and show IP
#if DECODE_HASH
  // Ignore messages with less than minimum on or off pulses.
  irrecv.setUnknownThreshold(kMinUnknownSize);
#endif  // DECODE_HASH
  irrecv.setTolerance(kTolerancePercentage);  // Override the default tolerance.
  irrecv.enableIRIn();  // Start the receiver
}

// The repeating section of the code
void loop() {
  // Check if the IR code has been received.
  if (irrecv.decode(&results)) {

	// Display a crude timestamp.
	uint32_t now = millis();
	Serial.printf(D_STR_TIMESTAMP " : %06u.%03u\n", now / 1000, now % 1000);
	// Check if we got an IR message that was to big for our capture buffer.
	if (results.overflow)
	  Serial.printf(D_WARN_BUFFERFULL "\n", kCaptureBufferSize);
	// Display the library version the message was captured with.
	Serial.println(D_STR_LIBRARY "   : v" _IRREMOTEESP8266_VERSION_ "\n");
	// Display the tolerance percentage if it has been change from the default.
	if (kTolerancePercentage != kTolerance)
	  Serial.printf(D_STR_TOLERANCE " : %d%%\n", kTolerancePercentage);
	// Display the basic output of what we found.
	Serial.print(resultToHumanReadableBasic(&results));
	// Display any extra A/C info if we have it.
	String description = IRAcUtils::resultAcToString(&results);
	if (description.length()) Serial.println(D_STR_MESGDESC ": " + description);
	yield();  // Feed the WDT as the text output can take a while to print.
#if LEGACY_TIMING_INFO
	// Output legacy RAW timing info of the result.
	Serial.println(resultToTimingInfo(&results));
	yield();  // Feed the WDT (again)
#endif  // LEGACY_TIMING_INFO
	// Output the results as source code
	Serial.println(resultToSourceCode(&results));

	// Draw the next strip containing the signal. Scale to fit the screen, and the length of the signal.
	double timingTotal = 0;
	int arrayLength = getCorrectedRawLength(&results);
	uint16_t *timings = resultToRawArray(&results);
	for (int i = 0; i < arrayLength; i++) {
	  timingTotal += timings[i];
	}

	int y = stripNum * stripHeight;
	int currentTotal = 0;
	double scaler = (double)dispWidth / (double)timingTotal;
	uint16_t col = 1;

	for (uint16_t i = 0; i < arrayLength - 1; i++) {
	  double timeWidth = ((double)timings[i] * scaler);
	  double timeX = (currentTotal * scaler);
	  currentTotal += timings[i];

	  M5.Lcd.fillRect((int)timeX, (int)y, (int)timeWidth, stripHeight - 2, col ? BLACK : WHITE);
	  col = 1 - col;
	}
	if (++stripNum == stripsDownScreen) stripNum = 0;




	Serial.println();    // Blank line between entries
	yield();             // Feed the WDT (again)
  }
}

Right now in August 2021, there's two types of M5Go bottom, M5Go, and M5Go2.

The M5Go2 remaps Port C's pins that are used on the Core2 for the PSRAM. This means that there's no unsoldering needed on the Core2 to use Port C, and the PSRAM now stays enabled! Yay!
(If you DID try using your M5Go (not M5Go2) on a Core2... you'd break PSRAM support. Core2 NEEDS a M5Go2.)

Here are the pin positions for Port A, Port B, and the Grove port, for the Core and Core 2:

Core (M5Go):
Port A (Red) : Pins SCL 22, SDA 21 : I2C, Supports digital and I2C mode,
Port B (Black) : Pins DAC 26, ADC 36 : DAC/ADC, Is generic IO
Port C (Blue) : Pins TX 16, RX 17 : Supports UART mode however outside of UIFlow the IO pins of the esp32 support various different modes.

Core 2 (M5Go2 bottom):
Port A (Red) : Pins SCL 32, SDA 33 : I2C, Supports digital and I2C mode,
Port B (Black) : Pins DAC 26, ADC 36 : DAC/ADC, Is generic IO
Port C (Blue) : Pins TXD2 14, RXD2 13 : Supports UART.

Just like the title says!

I've got a Core2 and the IR Sensor module. It's got a black connector for "Port B" on the Core2.

The Core Grey doesn't have a Port B, but it does have a red Grove!
Am I right in thinking the GND and +5 volts are the same pin positions on both?

Does that mean I could potential change out the two data pins for Port B, to be those of the Grove port?

I get that the Grove port and Port A and B have hardware support for some things like IC2, and erm... other control protocols. But for the IR Sensor, I believe I can use the pins in software, directly, just using "writeDigital" and "readDigital" ?

Am I about to blow up my Core Grey!?

It turned out to be my Ryzen Swift 3 USB drivers!

After updating them the problem resolved.

https://github.com/Sarah-C/M5Stack_Core2_ScreenBrightness

You might have noticed that setBrightness() doesn't do anything on the Core2, and ScreenBreath() seems dodgy. (See this: https://github.com/m5stack/M5Core2/issues/20 )

So while the complexities of the AXP192 registers are ironed out, I've created a function called core2Brightness(). It's not in a library, you just copy and paste it into your Arduino .ino sketch file.

core2Brightness() physically turns your backlight off at level 0, and increases the dimmable range of the backlight all the way down to "barely visible in absolute darkness".
It uses the absolute minimum discrete brightness levels enabled by the AXP192 library, so every value from 0 through 20 produces an observable change in brightness, unlike other available functions. =)

If you're a rebel, it can also increase the brightness range using the "turbo mode", but the official M5Stack view is not to do it, or for very short periods only else overheating and LED damage can occur. It's obvious damage, it'll void your warranty. You can't send it back if you overdrive it and it pops.

Help!

When I try uploading a sketch using Windows 10, and Arduino 1.8.15 to my Core2 I get the following:

"Connecting...................................____
A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header"

If I just select the "Serial Monitor" while the Core2's plugged in - when I reboot the Core 2, the Serial Monitor shows the bootup text, so the device is definitely connected AND communicating through all the USB ports I tried.

The Core Grey I bought earlier is working fine... it flashes every time without issue.

I've tried the following:

1. I've used both USB cables that came with my Core Grey and Core2, and a 3rd party cable. (all three work with my Core Grey)
2. I've slowed down/turned off the LIFO stacks in Device Manager for COM4 - where the device appears.
3. I've slowed down the connection via Device Manager. (same windows as #2)
4. Uninstalled Arduino software, then reinstalled.
5. Used Device Manager to uninstall the serial drivers (ticked "From disk" too), then reinstalled by reinstalling the Arduino software.
6. Googled online..... only found this for a bare ESP32 board: https://randomnerdtutorials.com/solved-failed-to-connect-to-esp32-timed-out-waiting-for-packet-header/
7. Tried the USB 3 laptop socket (blue plastic).
8. Tried the USB 2 laptop socket.
9. Powered off the laptop and powered back on.
10. Removed the Core2 battery, and tried flashing again.
11. Tried using the esptool.exe 3.0-dev version on the command line in a temporary batch file. (same message)
    Command: "esptool.exe --chip esp32 --port COM8 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 C:....esp32\1.0.6/tools/partitions/boot_app0.bin 0x1000 C:....esp32\hardware\esp32\1.0.6/tools/sdk/bin/bootloader_dio_80m.bin 0x10000 C:....\arduino_build_567398/circles.ino.bin 0x8000 C:....\Temp\arduino_build_567398/circles.ino.partitions.bin"
12. Tried tapping the Reset button while "Connecting..." is being displayed.
13. Arduino settings: Ensured the board is "M5Stack-Core2"
14. Arduino settings: Tried 115200 for the upload speed.
15. Tried a hub plugged into the laptop.
16. Tried an externally powered USB 3 hub.

I've ran out of things to try!

Do I need a new Core2? How do I go about it? I don't want my money back - I love the touchscreen!

https://docs.m5stack.com/en/core/gray
On the spec grid it says: Flash Memory............ 16MB (old: 4MB)

But checking the Arduino boards.txt file:
m5stack-core-esp32.name=M5Stack-Core-ESP32
m5stack-core-esp32.upload.tool=esptool_py
m5stack-core-esp32.upload.maximum_size=1310720
m5stack-core-esp32.upload.maximum_data_size=327680
m5stack-core-esp32.build.board=M5Stack_Core_ESP32
m5stack-core-esp32.build.f_cpu=240000000L
m5stack-core-esp32.build.flash_size=4MB

4MB!

My question then is..... Am I able to upload a program to my Core-Grey that shows available Flash memory that WON'T be effected by what Arduino thinks it should be? My concern is that these details here will effect what the functions report after the sketch is uploaded, and I'll never see 16MB if it's there.

( C:\Users[--user--]\ AppData\Local\ Arduino15\packages\ esp32\hardware\esp32\ 1.0.6\boards.txt )

My plan is to tweak the boards.txt file to match the Core2 if I find the board has 16MB flash.

It's a pity that the M5Stack new revision with 16MB flash doesn't report itself as a slightly different version, so IDE's like Arduino can see them!