No data on Grove C/UART2 ...

buhhe

Hi,

For days now i've tried to get serial data via UART2/Grove Port-C, without any success.
I have a M5 Fire, and the external data source is an Ublox NEO M8N, sending its data with 9600Baud, 8N1.
PSRAM is disabled in the Arduino-IDE (since yesterday V.1.8.10).
For checking the data coming from the Ublox i've connected the Grove plug (coming from the Ublox) with my PC and and an Arduino. Both works fine. They get lot of NMEA data. Even when the receiver gets no valid satellite data it sends NMEA data. Only the M5 gets not a Bit.
Neither Serial2.begin()/Serial2.read() nor GPSRaw(2)/GPSRaw.begin()/GPSRaw.read() leads to success.
Is there a way to check the properly working of uart2?
Ideas and advices are very apprecited.

Thanks.

buhhe

I've got some insights and found a solution now.

You can't use Grove Port C for serial communication. You can't use Port C for anything. Since the PSRAM is soldered to the board it's not pssible to disable it. The PSRAM uses the same pins as Port C (16, 17). My conclusion is: forget Port C (don't no why it is not connected to other -usable- pins at the M5Stack Fire PSRAM model).
Grove Port C is not the only port usable for serial communication (exept the USB port). You can e.g. use Port B. Therefore you have to allocate the pins of Port B (26, 36). This short example works with an external GPS reveiver connected to Grove Port B:

#include <M5Stack.h>

#define GPIO_PIN26 26
#define GPIO_PIN36 36

HardwareSerial GPSRaw(2);

void setup()
{
M5.begin();
GPSRaw.begin(9600, SERIAL_8N1,GPIO_PIN36,GPIO_PIN26);
Serial.println("Started ...");
}

void loop()
{
if(GPSRaw.available())
Serial.write(GPSRaw.read());
}

m5stack

The GPIO 16 / 17 in Fire is connected to the PSRAM by default, so when you connect or stack other function modules, you need to avoid conflicts with these two pins to prevent the device from working properly and causing instability.

buhhe

Thanks for the advice. Honestly, 21 days earlier it would have been appreciated and it doesn't contain any additional information after my post.

My solution works fine and maybe it helps other struggling people in this mainly undocumented eco system.

The remaining question is why connects M5Stack the Grove Port C in the Fire in a way that makes it totally useless?

And why is the Grove Port C documented here even it serves only decoration purposes instead:
https://docs.m5stack.com/#/en/core/fire ?

lukasmaximus

Hi @buhhe sorry for your disappointment we are actively trying to improve the documentation and apologize that they were lacking the information you required. If you require more info regarding using the ublox modules with M5Stack one of our users rick macdonald of rocketmanrc has worked extensively with them and probably could share some valuable advice, and he's always happy to share https://www.rocketmanrc.com/contact.html he made this open pps system with m5stack and ublox https://www.rocketmanrc.com/openpps.html

liemph

@lukasmaximus @buhhe Since I purchased an M5Stack Fire, I just want to reconfirm the Buhhe's statement that we can not use completely Port C of M5FIRE. Is it true?

liemph

@buhhe I think this is a useful solution not only for your specific problem but for other owners of M5Stack Fire. Thanks for this information since I am just thinking of using the available ports of this module.

buhhe

@liemph Thanks for the feedback and i hope my solution helps!
I had asked the M5Stack support for that problem and they wrote me "The PSRAM was soldered on to the board. Cant disable it." That implies in my understandig that the Port C cannot used since the PSRAM uses the same pins as Port C. And looking closer to the M5Stack support-replies above shows no contradicition to my assumes but only some unclear statements and regrets.
For me is no doubt that the Port C of the "Fire" is a kind of rudiment of earlier M5Stack versions. The Port is not usable in the "Fire".

Thrasher

Unsolder it :D

liemph

@buhhe said in No data on Grove C/UART2 ...:

@liemph Thanks for the feedback and i hope my solution helps!
I had asked the M5Stack support for that problem and they wrote me "The PSRAM was soldered on to the board. Cant disable it." That implies in my understandig that the Port C cannot used since the PSRAM uses the same pins as Port C. And looking closer to the M5Stack support-replies above shows no contradicition to my assumes but only some unclear statements and regrets.
For me is no doubt that the Port C of the "Fire" is a kind of rudiment of earlier M5Stack versions. The Port is not usable in the "Fire".

Ok, I have to give up or unsoldering the pin which I certainly will not do it.
My decision of buying the FIRE version of M5Stack core was based partly on the PSRAM. I think it is a faulty design.

SarahC

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.

UKTechguy

@sarahc Many thanks for the very useful info - If only it was more widely available/published it would have saved me hours of frustration!!!