Issues Initializing MAX-M10S GNSS on ZephyrRTOS

[AarC10]

Hello.

Currently trying to integrate ubxlib into my software which utilizes ZephyrRTOS on an STM32 F446RE. I've worked through a few issues, but my teammate and I seem to be stumped on getting uDeviceOpen to work. At this point, we have ran into a U_ERROR_COMMON_PLATFORM (-8) error code both when trying to use I2C or UART. The -8 error occurs from trying to power on the GNSS and doing the controlled GNSS hot start. Trying to do a GNSS hot start which runs uGnssPrivateSendReceiveUbxMessage yields a U_ERROR_COMMON_DEVICE_ERROR (-10). We can confirm the chip works since we can probe the UART lines and see messages being output from the GPS chip regardless of the software being ran. Can also confirm we were able to communicate with the chip and get GPS data before using Zephyr and ubxlib and were using our own custom drivers and software over I2C. Was hoping to get some support on determining what the issue could be and if there needs to be any improvements to our software, Here is some of our relevant code, debug logs and gdb showing our system state. Thank you for your time.

Calling Code:

int init_maxm10s(gnss_dev_t *dev) {
    int ret = uPortInit();
    if (ret != 0) {
        LOG_ERR("uPortInit() returned %d\n", ret);
        return ret;
    }

    ret = uPortI2cInit();
    if (ret != 0) {
        LOG_ERR("uPortI2cInit() returned %d\n", ret);
        return ret;
    }

    ret = uDeviceInit();
    if (ret != 0) {
        LOG_ERR("uDeviceInit() returned %d\n", ret);
        return ret;
    }

    ret = uDeviceOpen(NULL, &dev->gnssHandle);
    if (ret != 0) {
        LOG_ERR("uDeviceOpen() returned %d\n", ret);
        return ret;
    }

    return 0;

}

Device Tree:

/ {
    cfg-device-gnss {
            compatible = "u-blox,ubxlib-device-gnss";
            status = "okay";
            transport-type = "i2c1";
    //        transport-type = "usart2";
            module-type = "U_GNSS_MODULE_TYPE_M10";
        };

    aliases {
        ubxlib-uart2 = &usart2;
    };
}

&usart2 {
    pinctrl-0 = <&usart2_tx_pa2 &usart2_rx_pa3>;
    pinctrl-names = "default";
    current-speed = <9600>;
    status = "okay";
};

&i2c1 {
    pinctrl-0 = <&i2c1_scl_pb6 &i2c1_sda_pb7>;
    pinctrl-names = "default";
    status = "okay";
    clock-frequency = <I2C_BITRATE_FAST>;

    max0: maxm10s@42 {
        status = "okay";
        compatible = "u-blox,maxm10s";
        reg = <0x42>;
    };
};

Config:

# U-Blox
CONFIG_GNSS=y
CONFIG_GNSS_SATELLITES=y
CONFIG_GNSS_NMEA0183=y
CONFIG_UBXLIB=y
CONFIG_UBXLIB_GNSS=y

# Need the following for U-Blox as well
CONFIG_INIT_STACKS=y
CONFIG_THREAD_STACK_INFO=y
CONFIG_THREAD_NAME=y
CONFIG_KERNEL_MEM_POOL=y
CONFIG_HEAP_MEM_POOL_SIZE=20000
CONFIG_MINIMAL_LIBC_MALLOC=n

[RobMeades]

Hi there, and sorry you're having trouble with this.

Your code and your configuration looks good to me and, from the evidence of the U_PORT_BOARD_CFG prints, the configuration seems to be being adopted by this code. The failure cases between UART and I2C are different in that, in the UART case, this code believes it has sent b5 62 0a 06 00 00 10 3a and has timed-out after waiting 10 seconds for the response, while for the I2C case the "sent command:" debug print is missing and the error is pretty much immediate.

That said, it looks as though your gdb screenshot is from the I2C case, which says that, even in that case, it is still getting all the way to trying to send the command, which implies that this line is likely returning U_ERROR_COMMON_DEVICE_ERROR, which can only happen if i2c_transfer() is returning an error.

As a next data point, at least for the I2C case, it is probably worth trying to find out what i2c_transfer() is returning.

Do you happen to be able to sniff the I2C or UART lines at all? Not necessary yet, but might turn out so. EDIT: I see you have already said that you can do this above. It would be interesting to know, in either the UART or I2C cases, if you can see the MCU sending the command to the GNSS device.

[RobMeades]

Looking at your device tree stuff, I notice you have:

   max0: maxm10s@42 {
        status = "okay";
        compatible = "u-blox,maxm10s";
        reg = <0x42>;
    };

...in the I2C entry, which I guess is for another driver inside Zephyr. Is it possible that driver is somehow still trying to do something, might somehow be active? Not that it should cause i2c_transfer() to return an error, of course, just thought I'd point it out.

[RobMeades]

Do you happen to be able to sniff the I2C or UART lines at all? Not necessary yet, but might turn out so.

I see you have already said that you can do this above. It would be interesting to know, in either the UART or I2C cases, if you can actually see the MCU sending the command b5 62 0a 06 00 00 10 3a to the GNSS device.

[Naquino14]

Looking at your device tree stuff, I notice you have:

   max0: maxm10s@42 {
        status = "okay";
        compatible = "u-blox,maxm10s";
        reg = <0x42>;
    };

...in the I2C entry, which I guess is for another driver inside Zephyr. Is it possible that driver is somehow still trying to do something, might somehow be active? Not that it should cause i2c_transfer() to return an error, of course, just thought I'd point it out.

Aaron and I were working on this together. When I removed it (at the time I was also only calling uDeviceOpen in init_maxm10s per the requirements of /port/platform/zephyr/Readme.md) uDeviceOpen returned -2. It would be helpful to test again though, so I will pull Aaron's changes and delete that node in the tree and let you know what I find.

[AarC10]

To follow up, we added some inits so the mutexes would get initialized so it stopped returning -2, so this no longer seems to be an issue. We also are not using any other outside driver, so I guess that the GPS definition inside i2c1 is unnecessary. We can use a Saleae to try probing UART to double check, but probing I2C will not be possible on this board. We could also try to get a breakout and write an overlay for a F446 nucleo and probe those lines and report back then if nothing else seems to be of concern.

[RobMeades]

Thanks: there really shouldn't be a need to probe HW lines for something this basic: there's just something misaligned somewhere between what ubxlib thinks is connected, what Zephyr thinks is connected, and what is actually connected.

For I2C, getting the return value of i2c_transfer() should tell us quite a lot I hope.

[djfurie]

Can you try adding i2c-address = <0x42>; to your device tree definition for the max0?

    gps {
        status = "okay";
        compatible = "u-blox,ubxlib-device-gnss";
        transport-type = "i2c2";
        i2c-already-open;
        i2c-address = <0x42>;
        module-type = "U_GNSS_MODULE_TYPE_M10";
    };

I believe that there may be a bug in the DT bindings that default the i2c address to 42 instead of 0x42

Edit: fixing the address only got me a few lines further in the code (to line 2372). However, without specifying 0x42 I was seeing NACKs, now I'm seeing valid traffic on I2C. But it times out while polling for whatever it's looking for.

Edit2:
Am I interpreting the packet right? Class = 0x0A ID = 0x06? I'm not seeing this message in the documentation.

gdb) where
#0  sendReceiveUbxMessage (pInstance=0x20008e48, messageClass=<optimized out>, messageId=<optimized out>, pMessageBody=<optimized out>, messageBodyLengthBytes=messageBodyLengthBytes@entry=0, pResponse=pResponse@entry=0x200052e0 <_k_thread_stack_mainThread_id+3424>)
    at /home/dan/projects/gps_project/firmware/deps/ubxlib/gnss/src/u_gnss_private.c:700
#1  0x0801b870 in uGnssPrivateSendReceiveUbxMessage (pInstance=pInstance@entry=0x20008e48, messageClass=messageClass@entry=10, messageId=messageId@entry=6, pMessageBody=pMessageBody@entry=0x0, messageBodyLengthBytes=messageBodyLengthBytes@entry=0, pResponseBody=<optimized out>, 
    pResponseBody@entry=0x20005310 <_k_thread_stack_mainThread_id+3472> "", maxResponseBodyLengthBytes=maxResponseBodyLengthBytes@entry=120) at /home/dan/projects/gps_project/firmware/deps/ubxlib/gnss/src/u_gnss_private.c:2555
#2  0x0801b9ea in uGnssPrivateSendOnlyCheckStreamUbxMessage (pInstance=pInstance@entry=0x20008e48, messageClass=messageClass@entry=6, messageId=messageId@entry=4, pMessageBody=pMessageBody@entry=0x200053c0 <_k_thread_stack_mainThread_id+3648> "", 
    messageBodyLengthBytes=messageBodyLengthBytes@entry=4) at /home/dan/projects/gps_project/firmware/deps/ubxlib/gnss/src/u_gnss_private.c:2358
#3  0x0800492a in uGnssPwrOn (gnssHandle=0x20008e08) at /home/dan/projects/gps_project/firmware/deps/ubxlib/gnss/src/u_gnss_pwr.c:578
#4  0x08004b16 in addDevice (gnssTransportHandle=gnssTransportHandle@entry=..., deviceTransportType=<optimized out>, pCfgGnss=pCfgGnss@entry=0x200054f0 <_k_thread_stack_mainThread_id+3952>, pDeviceHandle=pDeviceHandle@entry=0x200054e4 <_k_thread_stack_mainThread_id+3940>)
    at /home/dan/projects/gps_project/firmware/deps/ubxlib/common/device/src/u_device_private_gnss.c:181
#5  0x08004c3a in uDevicePrivateGnssAdd (pDevCfg=pDevCfg@entry=0x200054e8 <_k_thread_stack_mainThread_id+3944>, pDeviceHandle=pDeviceHandle@entry=0x200054e4 <_k_thread_stack_mainThread_id+3940>) at /home/dan/projects/gps_project/firmware/deps/ubxlib/common/device/src/u_device_private_gnss.c:303
#6  0x08002a6e in uDeviceOpen (pDeviceCfg=0x0, pDeviceHandle=pDeviceHandle@entry=0x20001ca0 <gps_device_handle>) at /home/dan/projects/gps_project/firmware/deps/ubxlib/common/device/src/u_device.c:289
#7  0x080070f2 in gps_init () at /home/dan/projects/gps_project/firmware/myprojectname/application/src/gps.c:39
#8  0x08006086 in mainThread () at /home/dan/projects/gps_project/firmware/myprojectname/application/src/main.c:58
#9  0x080078ce in z_thread_entry (entry=0x200008d4 <log_dynamic_app>, p1=0x0, p2=0x0, p3=0x0) at /home/dan/projects/gps_project/firmware/deps/zephyr/lib/os/thread_entry.c:48
#10 0xaaaaaaaa in ?? ()

So I'm very confident I'm looking at the same issue, and have confirmed that what is actually going out over the wire is wrong. I believe the intended message is a UBX-CFG-RST (0x06 0x04).

[djfurie]

I see in the code that it should be a UBX-MON-MSGPP that is being sent.

That type doesn't appear in the M10 software guide. Appears that it's not supported?
https://content.u-blox.com/sites/default/files/u-blox-M10-SPG-5.10_InterfaceDescription_UBX-21035062.pdf

It's a defined message for the M8 series:
https://content.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf

[RobMeades]

I believe that there may be a bug in the DT bindings that default the i2c address to 42 instead of 0x42

Woohoo! Well spotted: when I end-to-end tested this I did so on SPI (thinking that was the most complex case) not on I2C so that would have got past me.

On the opening message sequence, this is what it should look like; this is a log from talking to an M10, so it was certainly there in this FW version (FWVER=SPG 5.10, PROTVER=34.10):

U_GNSS: sent command b5 62 0a 06 00 00 10 3a.
U_GNSS: decoded UBX response 0x0a 0x06: 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [body 120 byte(s)].
U_GNSS: sent command b5 62 06 04 04 00 00 00 09 00 17 76.
U_GNSS: sent command b5 62 0a 06 00 00 10 3a.
U_GNSS: decoded UBX response 0x0a 0x06: 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [body 120 byte(s)].

I will investigate...

[djfurie]

Thanks for the message sequence. That will be helpful for debugging further, as I'm obviously a bit confused about what messages should be passing when =)

[djfurie]

Will revisit this tomorrow, but my last data point is that I don't seem to get any response after the UBX-MON-MSGPP is sent. I just observe reads of the 0xFD register, which returns 0xFF 0xFF, and then a lot of bytes read from the 0xFF register. This repeats for a while until things time out.

[RobMeades]

You're absolutely right that the MAX-M10 interface manual doesn't mention the UBX-MON-MSGPP message, which I hadn't noticed 'cos the MAX-M10 devices we have in the ubxlib test system, devices which report FWVER=SPG 5.10, PROTVER=34.10 (which are the versions the interface manual says it is for), respond to it.

EDIT: curiously the interface manual does include the configuration message to configure the rate of the UBX-MON-MSGPP message on I2C, SPI and UART (CFG-MSGOUT-UBX_MON_MSGPP_XXX).

Very odd. I will enquire with people who should know tomorrow.

[RobMeades]

One more thing: in your I2C trace, a read from register 0xFD produces the response 0xFF 0xFF.

If there were no data to be read, I would expect it to produce the response 0x00 0x00; see below a portion from an I2C trace I happened to take a few days ago with a MAX-M10S:

The response you are getting would appear to mean that there are at least 65535 bytes of data to be read, which might take a little while, possibly explaining the timeout?

I guess a fix for this would be to not do the UBX-MON-MSGPP either side of the UBX-CFG-RST, i.e. to call uGnssPrivateSendOnlyStreamUbxMessage() instead of uGnssPrivateSendOnlyCheckStreamUbxMessage() just here:

ubxlib/gnss/src/u_gnss_pwr.c

Lines 575 to 578 in 980e327

	// The message is not acknowledged, so must use
	// uGnssPrivateSendOnlyCheckStreamUbxMessage()
	message[2] = 0x09; // Controlled GNSS hot start
	if (uGnssPrivateSendOnlyCheckStreamUbxMessage(pInstance,

That would make it more of a "best effort" reset but it would then work in situations where the GNSS chip might have been left on and accumulating messages for some time before we are attached to it.

[RobMeades]

A fix to apply the correct default I2C address is available in a preview branch here:

https://github.com/u-blox/ubxlib/tree/preview_fix_zephyr_dts_gnss_rmea

...should anyone need it. I will update this issue when the fix is pushed to the master branch and will delete the preview branch some time after that.

EDIT: fix now pushed to master here in commit fdc78b8.

[cturvey]

UBX-MON-MSGPP is supported on SPG 5.00 and SPG 5.10

0x20910196 CFG-MSGOUT-UBX_MON_MSGPP_I2C
0x20910197 CFG-MSGOUT-UBX_MON_MSGPP_UART1
0x2091019A CFG-MSGOUT-UBX_MON_MSGPP_SPI