.begin fails on Thing Plus RP2040 - need to edit pins_arduino.h

[StressedDave]

I'm having an issue interfacing the library with anything with a RP2040 processor (I've tried the code on a ThingPlus, Feather and Trinkey). It may be someone has messed around with the Arduino core. Put very simply, 99% of the time a call to begin() throws up a 'unable to connect' error. I know the board is there because:

`#include <Wire.h> //Needed for I2C to GNSS
#include <SparkFun_u-blox_GNSS_Arduino_Library.h> //http://librarymanager/All#SparkFun_u-blox_GNSS

SFE_UBLOX_GNSS GNSS;

boolean UDR = false;
char Model[30];

void setup()
{
Serial.begin(115200); // You may need to increase this for high navigation rates!
while (!Serial)
; //Wait for user to open terminal
Serial.println("Configuration check");
Wire1.begin();
Wire1.beginTransmission(0x42);
if((Wire1.endTransmission() == 0)){
Serial.println("YES - I am definitely here");
}
else{
Serial.println("NO - I am not here");
}
GNSS.begin(Wire1);
if (GNSS.begin(Wire1) == false) //Connect to the u-blox module using Wire port
{
Serial.println(F("u-blox GNSS not detected. Please check wiring. Freezing."));
while (1)
;
}
GNSS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise)
}

void loop()
{
}`

Confirms that the board is there but throws up the error when I go to start the library. A quick zoom through the source code suggests that you're using the same code in 'isConnected'. (Sorry, I'm of an age where Pascal/Fortran was king of languages for University). Am I missing something? The library starts correctly on every other processor I've tried (SAMD M0 & M4 and STM32) and used to work fine on RP2040 architecture.

I'm trying to interface a M8U (and I spotted in the source that they occasionally throw up issues), but a M9N shows the same behaviour.

[PaulZC]

Hi @StressedDave ,

I'm seeing the same thing with: ZED-F9P breakout; SparkFun Thing Plus RP2040; SparkFun u-blox GNSS Library 2.2.20; Arduino Mbed OS RP2040 Boards 3.4.1. The .begin fails when trying to run Example3_GetPosition...

.begin does use the same simple "endTransmission() == 0" isConnected test, but then goes on to do a u-blox UBX-CFG-PRT exchange to confirm if the module is actually connected and responding.

This might be a clock-stretching issue? Just a hunch...

I'll need to investigate further... But it will take me a few days with Christmas just over the horizon. I'll try and come back to you by the middle of next week.

Until then,
Paul

[PaulZC]

Hi @StressedDave ,

OK. Panic over... I took a quick look at this and it is - I think - purely down to a pin numbering issue.

Have a look at this section of the hook-up guide and scroll down to where it talks about needing to edit pins_arduino.h to make SPI work correctly:

https://learn.sparkfun.com/tutorials/rp2040-thing-plus-hookup-guide/software-overview

Turns out, you need to do the same thing for the I2C SDA and SCL pins. I changed PIN_WIRE_SDA to (6u) and PIN_WIRE_SCL to (7U) and then the example started correctly.

Please give this a try. It should get you going.

Closing... Please re-open if you are still having problems or need extra help.

Merry Christmas!
Paul

[PaulZC]

Hi @StressedDave ,

Also, you need to use Wire, not Wire1...

Best,
Paul

[StressedDave]

It's working . It'll go through a few cycles of not responding, then it'll be fine. I wonder it it needs a delay put in isConnected() to let things settle. I'll have a fiddle over the Christmas break and see if that helps.

I'm using Earl Philhowers core rather than mBed though. Last time I had a sketch working, I had to use his SetSDA/SCL functions to set the I2C pins (even though they were the pins_arduino.h) before it would work.

[StressedDave]

It's still sufficiently inconsistent as to be causing a problem - the GNSS receiver is hidden away and not easily accessible in its end-use. Fortunately I can reconfigure the Qwiik port to be serial rather than I2C and get around it. Failing that I'll put a WDT reset loop in and see how many times it takes before it does work.

There's clearly something nasty going on with the combination of the RP2040 I2C and the u-Blox. Every other processor family I use connects straight off the bat.

[StressedDave]

And just to make it extra awkward, I've got a M9N that works everytime. Seems like the comments in the source about it ignoring the CFG-RATE poll is true.

[PaulZC]

Thanks for the update. I wonder if this is a clock-stretching issue after all?

Just for giggles - and only if the RP2040 supports non-standard clock speeds (I don't know if it does) - you could try running the bus at 10kHz. Does that change anything? It won't completely prevent clock-stretching, but will help prevent the majority of short clock-stretch events. From the M10 datasheet:

"The interface stretches the clock when slowed down while serving interrupts, therefore the real bit rates may be slightly lower. The maximum clock stretching time that the host can expect is 20 ms."

[StressedDave]

Yup - perfectly happy at 10kHz. Works at 25kHz too. Falls over at 100kHz. I'm doing a reasonable amount of post-processing so may need the higher rates, but that's my end rather than yours. The M8U datasheet is a little coyer than the M10 as to max. clock stretch.

I can survive over serial for now, so it's not a showstopper.

[PaulZC]

OK - good to know. Thanks!

(It's double the pin count, but SPI could be a good way forward?)

[StressedDave]

If only - the board I'm proposing (A Trinkey) has a single 2-pin port that can be either I2C or UART. It's for on-road driver behaviour assessment and there's always a USB port handy to plug into rather than having to have a thick USB cable running into a box that has to be really close to the port because there's no space to put it. It's a side effect of excessive internal styling in the modern supercar.