GNSS doesn't work with LilyGO TTGO T-Beam

[jagra26]

Hi, I'm trying to port LilyGO TTGO T-Beam to zephyr. I'm using the 3.7.0 release and the process is almost done. But the GPS module, a NEO-6m, isn't working with the gnss sample. My steps until now are:

First, I configured the UART pins to be coincident with T-Beam pinout, with RX on GPIO34 and TX on GPIO12, on pinctrl.dtsi:

uart1_default: uart1_default {
		group1 {
			pinmux = <UART0_TX_GPIO12>;
			output-high;
		};
		group2 {
			pinmux = <UART0_RX_GPIO34>;
			bias-pull-up;
		};
	};

Second, I seted UART on dts, defining NEO-6m like a generic module:

&uart1 {
	status = "okay";
	current-speed = <9600>;
	pinctrl-0 = <&uart1_default>;
	pinctrl-names = "default";
	gnssdev: gnss-nmea-generic {
    	    	compatible = "gnss-nmea-generic";
	};
};

And, of course, included gnssdev in aliases:

aliases {
		led0 = &led_io4;
		uart-0 = &uart0;
		i2c-0 = &i2c0;
		watchdog0 = &wdt0;
		lora0 = &lora0;
		gnss = &gnssdev;
		sw0 = &button_io38;
	};

The main.c code and prj.conf are the same of the sample. It builds and runs with no problems, but it doesn't return any data from GPS.
I know it isn't a hardware problem, because I have a functional arduino code.

Maybe i configured it wrong, or NEO-6m isn't compatible with gnss driver, but i don't know how to check this.

How to proceed?

[kartben]

Why are you using UART0_... in the pinctrl definition? Looks like this is where your problem might be and you should replace with UART1_... :)

[bjarki-andreasen]

Also, you need to set the status of your GNSS node and UART node to "okay" :) status = "okay";

[kartben]

Also, you need to set the status of your GNSS node and UART node to "okay" :) status = "okay";

Doesn't status default to okay? 🤔 I agree it can be helpful to be explicit but in this case I don't think it's strictly needed?

[bjarki-andreasen]

Also, you need to set the status of your GNSS node and UART node to "okay" :) status = "okay";

Doesn't status default to okay? 🤔 I agree it can be helpful to be explicit but in this case I don't think it's strictly needed?

It seems the macros with STATUS_OKAY do treat missing status as okay :) I just looked at the base.yaml binding :) maybe we should set the default there?

[kartben]

It seems the macros with STATUS_OKAY do treat missing status as okay :) I just looked at the base.yaml binding :) maybe we should set the default there?

DT spec says that it's perfectly fine to omit the property altogether, in which case it's treated as if the node is status="okay". Maybe setting a default would make sense (and would have the merit of making all the statuses explicitly show up in the generated zephyr.dts?), but this doesn't change the fact that the "treat missing as okay" behaviour always applies, even for bindings that doesn't extend base.yaml

[ASerbinski]

Depending on which version of T-Beam you have, there is also a power management chip (AXP192 or AXP2101) that you need to instruct to switch on the power supply to the GPS (also LoRa if you're using that).

Zephyr appears to have a driver for the AXP192 (drivers/regulator/regulator_axp192.c), but not the AXP2101.

[jagra26]

Hi guys, thanks for responses.

@kartben

Why are you using UART0_... in the pinctrl definition? Looks like this is where your problem might be and you should replace with UART1_... :)

It's my fault, I've tried various combinations, and ended with UART0. But, you are correct. Now, pinctrl.dtsi looks like:

uart1_default: uart1_default {
		group1 {
			pinmux = <UART1_TX_GPIO12>;
			output-high;
		};
		group2 {
			pinmux = <UART1_RX_GPIO34>;
			bias-pull-up;
		};
	};

@bjarki-andreasen

Also, you need to set the status of your GNSS node and UART node to "okay" :) status = "okay";

I've added your suggestion and dts looks like:

&uart1 {
	status = "okay";
	current-speed = <9600>;
	pinctrl-0 = <&uart1_default>;
	pinctrl-names = "default";
	gnssdev: gnss-nmea-generic {
		status = "okay";
    	    	compatible = "gnss-nmea-generic";
	};
};

But i have the same results, compiles, run and no data.

@ASerbinski

Depending on which version of T-Beam you have, there is also a power management chip (AXP192 or AXP2101) that you need to instruct to switch on the power supply to the GPS (also LoRa if you're using that).

Zephyr appears to have a driver for the AXP192 (drivers/regulator/regulator_axp192.c), but not the AXP2101.

I'm using T-Beam v1.1, and it uses the AXP192. At first, i thinked AXP192 doesn't make difference because the arduino code dosen't manipulate anything from AXP192. And GPS LED (see the schematic image) is blinking with the zephyr code runs.

But, after searching a lot i found in the lilygo website, a QRcode to a AXP192 configuration (yes, lilygo dosen't help with clear documentation). And, now, I have a north to follow and configure AXP192. I will try this tomorrow and bring news.

Again, thanks for the help @kartben, @bjarki-andreasen and @ASerbinski .

[kartben]

Great catch, @ASerbinski regarding the AXP192
@jagra26 check out how the couple of M5Stack boards in boards/M5Stack configure it, it shouldn't be too hard :) You might need to tweak init level to make sure AXP192 driver kicks in before GNSS driver

Btw, converting this to a discussion as there is a very good chance that there is no bug :)

[ASerbinski]

Another issue I just noticed;

On the T-Beam board, the GPS is attached to IO12 and IO34. According to the ESP32 datasheet, these pins are NOT connected to UART peripheral.

UART pins are U0: IO1/3 (console), U1: IO9/10 (used by flash/psram), and U2: IO16/17 (used by psram).

What that means is that communicating with the GPS will require either software-UART with the pins configured as GPIO, or hardware modification to attach to IO16/17 instead of IO12/34 AND disconnect PSRAM chip (ips6404 -- the smaller of the two 8-pin chips adjacent to the ESP32).

I don't think that there is a software UART driver implemented for zephyr.

Simple way to check if you need to muck with the AXP: Test for 3.3v at GPS pin 23.

[fmoessbauer]

What that means is that communicating with the GPS will require either software-UART with the pins configured as GPIO

I just ran into the same issue and think that this is indeed the problem.

[fmoessbauer]

@bjarki-andreasen Can we please re-open the original issue. The support for GNSS is definitely broken on that board and also cannot easily be fixed by just tweaking the regulators.

[jagra26]

Hi guys, I got a flu and can't work much on this these days. But I've tried a little.
@kartben I followed the M5Stack, specifically the m5stickc plus, and ended with this .dts:

#include <zephyr/dt-bindings/regulator/axp192.h>
&i2c0 {
	status = "okay";
	clock-frequency = <I2C_BITRATE_STANDARD>;
	sda-gpios = <&gpio0 21 GPIO_OPEN_DRAIN>;
	scl-gpios = <&gpio0 22 GPIO_OPEN_DRAIN>;
	pinctrl-0 = <&i2c0_default>;
	pinctrl-names = "default";
        axp192_pmic: axp192@34 {
		compatible = "x-powers,axp192";
		reg = <0x34>;
		status = "okay";

		axp192_regulator: axp192_regulator {
			compatible = "x-powers,axp192-regulator";
			status = "okay";

			vdd_mcu: DCDC1 {
				regulator-init-microvolt = <3350000>;
				regulator-min-microvolt = <3200000>;
				regulator-max-microvolt = <3400000>;
				regulator-initial-mode = <AXP192_DCDC_MODE_AUTO>;
				regulator-boot-on;
				regulator-always-on;
			};

			lora_vcc: LDO2 {
				regulator-init-microvolt = <3350000>;
				regulator-min-microvolt = <3200000>;
				regulator-max-microvolt = <3400000>;
				regulator-boot-on;
			};

			gps_vdd: LDO3 {
				regulator-init-microvolt = <3350000>;
				regulator-min-microvolt = <3200000>;
				regulator-max-microvolt = <3400000>;
				regulator-boot-on;
			};
		};
	};
};

It compiles and run. I followed the instructions of @ASerbinski and measure 3v3 on the pin 23 of GPS. But, I don't know why, i can't get any signal, with zephyr and arduino codes. I will try again this week in outside and with another board. Thanks for the help guys.