I2C: Strange behaviour trying to read PA1010D GPS

[Gadgetoid]

I've been testing the PA1010D i2c GPS (happy to supply one to anyone who's got a head for mysteries) with the Pico, starting with CircuitPython and reducing down to a minimum amount of C++ SDK code to reproduce.

Long story short, it will stall hard after about one i2c read using Pico's hardware I2C.

Using either CircuitPython bitbangio or the I2C PIO driver from the Pico Examples it will read perfectly happily and - indeed - in the same setup for testing this I've had valid GPS data pouring out using a CircuitPython example and bitbangio in lieu of hardware i2c.

Works:

#include <stdio.h>
#include "pico/stdlib.h"
#include "pio_i2c.h"

#define PIN_SDA 4
#define PIN_SCL 5

int main() {
    stdio_init_all();

    PIO pio = pio0;
    uint sm = 0;
    uint offset = pio_add_program(pio, &i2c_program);
    i2c_program_init(pio, sm, offset, PIN_SDA, PIN_SCL);

    uint addr = 0x10;

    while (1) {
        int ret;
        uint8_t rxdata[11];
        ret = pio_i2c_read_blocking(pio, sm, addr, rxdata, 10);
        rxdata[10] = '\n';
        printf(rxdata);
        sleep_ms(1000);
    }
    return 0;
}

Stalls:

#include <stdio.h>
#include "pico/stdlib.h"
#include "hardware/i2c.h"

int main() {
    stdio_init_all();

    i2c_init(i2c0, 100 * 1000);
    gpio_set_function(4, GPIO_FUNC_I2C);
    gpio_set_function(5, GPIO_FUNC_I2C);
    gpio_pull_up(4);
    gpio_pull_up(5);

    int addr = 0x10;

    while (1) {
        int ret;
        uint8_t rxdata[11];
        ret = i2c_read_blocking(i2c0, addr, rxdata, 10, false);
        rxdata[10] = '\n';
        printf(rxdata);
        sleep_ms(1000);
    }
    return 0;
}

I've played with the i2c baud rate to no avail. The hardware i2c seems to inevitably get stuck in this loop:

        do {
            abort_reason = i2c->hw->tx_abrt_source;
            abort = (bool) i2c->hw->clr_tx_abrt;
            if (timeout_check) {
                timeout = timeout_check(ts);
                abort |= timeout;
            }
        } while (!abort && !i2c_get_read_available(i2c));

CircuitPython suggested that either Data or Clock was pulled low, preventing the detection of i2c pull-ups once this state is entered. Using C++ to sleuth this further suggests that SDA is held low. It would seem to be the GPS itself that's entered a bad state and is holding SDA low. Why Pico's hardware i2c would cause it to do this totally eludes me. Unplugging the GPS and re-inserting it seems to clear this state.

Weirder still. If I get the GPS into a bad state whereupon it's totally unresponsive to hardware I2C, running the PIO I2C example will get it working again. I've tried this a few times. It's... odd.

And. I'm baffled.

[fivdi]

Something similar was seen with a BME280. See https://www.raspberrypi.org/forums/viewtopic.php?f=144&t=306875.

[fivdi]

Could it have something to do with this:

    // TODO there are some subtleties to I2C timing which we are completely ignoring here

[dhalbert]

I could not duplicate the BME280 issues in CircuitPython, even turning off our bitbangio. I replied in that RPi Forum thread.

[Gadgetoid]

Likewise. I've recently completed a C++ BME280/BMP280 driver for our pimoroni-pico repository and have not run into the issues described on the forums. Full driver is here: https://github.com/pimoroni/pimoroni-pico/blob/patch-bme280-breakouts-dev/drivers/bme280/bme280.cpp

[stackjohn]

Likewise. I've recently completed a C++ BME280/BMP280 driver for our pimoroni-pico repository and have not run into the issues described on the forums. Full driver is here: https://github.com/pimoroni/pimoroni-pico/blob/patch-bme280-breakouts-dev/drivers/bme280/bme280.cpp

@Gadgetoid Absolutely brilliant thank you for this! 😃

The issue I was having on the forums seem to be solved now, when writing to the bme280 you need to make sure the parameter here is true to take control of the bus.

int rc = i2c_write_blocking(I2C_PORT, addr, &reg, 1, true);

Also, the bus scan still seems to hang and perhaps leave the bme280 in a strange state. You must disconnect power from the bme280 (and maybe the pico as well?) to reset it into a good state.

Is there a way to set this parameter to true when using the pio i2c implementation?

https://github.com/raspberrypi/pico-examples/blob/master/pio/i2c/pio_i2c.c

[fivdi]

@Gadgetoid I'm going to risk taking another guess here as I don't have a PA1010D to test with.

Is it possible to fix this problem by adding this line of code

    i2c->hw->sda_hold = 2;

directly after this line of code

    i2c->hw->fs_spklen = lcnt < 16 ? 1 : lcnt / 16;

For me, this fixes what might be the same problem with the TCS34725. See also here.

[Gadgetoid]

Interesting hypothesis but I can't see any difference. I really should get a scope on this. I really can't fathom what would be confusing the PA1010D into driving SDA low.

[fivdi]

@Gadgetoid oh well, thanks for checking.

[riozebratubo]

Hi, @Gadgetoid.

I'm having an issue that could be related to this one. I'm trying to mod some arduino libraries that use hardware i2c to work on the raspberry pi pico, and I'm getting read fails if I try to read too much at once, too much being more than 4 bytes.

Could you please try to make your line:

ret = i2c_read_blocking(i2c0, addr, rxdata, 10, false);

Into 3 reads like that:

ret = i2c_read_blocking(i2c0, addr, rxdata, 4, false);
ret = i2c_read_blocking(i2c0, addr + 4, rxdata + 4, 4, false);
ret = i2c_read_blocking(i2c0, addr + 8, rxdata + 8, 2, false);

And see if it has any impact?

Thank you!

[Gadgetoid]

No improvement @riozebratubo ... running step debugging shows my program never reaches the second read, stalling on the first. If anything this might be worse! I think the PA1010D might be uniquely weird in this case though.

Again my basis for comparison - using PIO i2c - works absolutely fine every time... even somehow rescuing the PA1010D from its "stuck" state where it forces SD low and refuses to cooperate.

[riozebratubo]

Thank you for trying it anyway!