ZED-F9P SPI problems

[sgrunc_80]

Dear Sparkfun

since years we are successfully working with your products, mostly Thing Plus MCU boards and also GPS with ZED-F9R.
with that setup in the end we are mostly able to work how we need (SPI interface between the two and also a third Dual-port shield parallel on SPI).

In last months we wanted to start use also the other variant of ZED-F9P.
so ordered two board (GPS-16481) and after a brief setup already stumble in SPI problems:
I soldered the DSEL jumper and connected all the SPI lines, also update all the ZED-F9P firmware via U-Center.
anyway in the end only one of the two works via SPI, the second doesn’t (maybe few time did..) but via I2C works fine.
Also checking in the forum find out that this was an issue (not sure if from Ublox or from your boards).

ZED-F9P SPI: DSEL jumper has no effect

I would like to use SPI to communicate with my GPS-RTK2 (ZED-F9P). According to the hookup guide, this can be accomplished by closing the DSEL jumper on the back of the board, and doing so should disable the UART1 and I2C ports. This isn’t working. I’ve soldered over the gap in the DSEL jumper, connected SCK, MISO, MOSI, and a CS pin to my micro, and I get nothing. This is the same SPI bus which hosts another working SPI device, so I know the bus works. I modify the SparkFun_u-blox_GNSS_Arduino_Library code to enable debug logging via Serial and I see this, repeating: Sending: CLS:CFG ID:RATE Len: 0x0 Payload: sendSpiCommand: B5 62 6 8 0 0 E 30 sendCommand: Waiting for ACK response waitForACKResponse: TIMEOUT after 1100 msec. I hook up a logic analyzer and quickly realize that what I believe to be SPI MISO is still UART1 TX at 38,400 baud, reading out perfect NMEA sentences. Does anyone know why closing the DSEL jumper did not switch the board to enable SPI and disable UART1? Do I…

in the end thought that maybe just one of the two board was defective and so order two more (this time without SMA, GPS-15136).
unfortunately yet both of the two are showing the same SPI limitations, almost no one works as it should (also after firmware update and DSEL soldered..).

Now I want to know directly from you if you’re aware of these problems, if you already had debug it, if you maybe have made another labeling mistake on the board silkscreen or layout for SPI pins (like for the ZED-F9R, GPS-22660 or GPS-22693)
without only addressing it in the forum and not correcting on the product

GPS-22693 (ZED-F9R) Hookup Guide Rx/Tx Reversed?

You are correct; we’ll get the hookup guide fixed shortly - good catch!

(not so professional, it cost me 2 x PCB design by the way).

Anyway before starting some claim or warranty procedure, hope you maybe can better address this point.

Thanks

Regards

[PaulZC]

Hi @sgrunc_80 ,

I have noticed that the ZED-F9P can be reluctant to start in SPI Mode if it has previously been used for UART and/or I2C. I added some notes about this in the post you linked. Please connect via USB and try setting the Protocol In and Protocol Out using u-center and UBX-CFG-PRT: set UART1 and I2C to None; set SPI to UBX+NMEA+RTCM3. Ensure the configuration is saved to both Battery-Backed RAM and Flash using UBX-CFG-CFG. Then restart. That should get the SPI interface working.

The SPI pin labelling error was limited to the ZED-F9R board. The ZED-F9P boards are labelled correctly.

We have used SPI very successfully in the RTK Reference Station. The interface between the ESP32 and the GNSS is exclusively SPI.

I hope this helps,
Paul

[sgrunc_80]

Hi,
thanks for the prompt reply.
anyway tried again with your suggestion but only solved the problem partially:

here the simple code we are using to debug. we use an SPI connection of 4 MHz and also tried lower (e.g. 1 MHz) but having the same issue)
ZED-F9P firmware v 1.51

  #include <SPI.h> 
  #include <SparkFun_u-blox_GNSS_v3.h> //http://librarymanager/All#SparkFun_u-blox_GNSS_v3
  SFE_UBLOX_GNSS_SPI myGNSS;


  #define spiPort SPI

  #define CS_SD A5      //  SD A5
  #define CS_GPS 6      // GPS

  
  void setup() {
  Serial.begin(115200);
  
  // set the CS of GPS/SD card SPI to high (to force it in case of a reset)
  pinMode(CS_GPS, OUTPUT);
  digitalWrite(CS_GPS, HIGH);

  Serial.println("start test");
  spiPort.begin();
  
  delay(50);

  // Do a fake transaction to initialize the SPI pins
  spiPort.beginTransaction(SPISettings(4000000, MSBFIRST, SPI_MODE0));
  spiPort.transfer(0xff);
  spiPort.endTransaction();

  Serial.println("Fake SPI success");
  delay(50); 
  
  bool begun = false;
  do {
    Serial.println("SPI begin");
    begun = myGNSS.begin(spiPort, CS_GPS, 4000000);

      //Serial.println("SPI loop");
    
    if (!begun) {
      Serial.println(F("u-blox GNSS not detected on SPI bus."));

      delay(1000);
    }
  } while (!begun);

  delay(50);
  Serial.println("Waiting for ZED F9P to connect over SPI");

  myGNSS.setAutoPVT(true); //Tell the GNSS to "send" each solution
}

actually we have three board ZED-F9P:

• 2 x GPS-15136 (No. 1, 2),
• 1 x GPS-16481 (No. 3)
  in attachment the type of results we are getting

unfortunately only sometimes they communicate and also then most are errors.
i still believe this Board (HW) or the SW (Library) aren’t properly working, for sure not well like the ZED-F9R model used before (only with 1x ZED-F9P about 4 (1xGPS-16481 is the only one which seems to work reliably..)
Do you think there are other better way to use it via SPI? I2C is maybe limited for what we need.
Currently on this status we cannot use the Boards as wished.

[PaulZC]

Hi Dan (@sgrunc_80 ),

This is strange… As I mentioned we use SPI in the RTK Reference Station, and the firmware uses the same SparkFun_u-blox_GNSS_v3 library to handle the communication. That product works very well.

Please tell me more about your hardware setup. Which processor / microcontroller board are you using? How do you have the two boards connected? Please share a photo showing the connections between the boards if you can.

You haven’t shared all of your code. Please also share the loop with the call to getModuleInfo.

Best wishes,
Paul

[PaulZC]

Also, I see #define CS_SD A5 // SD A5 in your code. That suggests you also have an SD card connected. Is it sharing the same SPI bus? You do not initialize the CS_SD pin. Please try adding:

pinMode(CS_SD, OUTPUT);
digitalWrite(CS_SD, HIGH);

Does that help?

[sgrunc_80]

Hi, the SD is on the same SPI bus, in this test code only left because the hw is always connected too. Tomorrow will try and say more.

The HW setup is simply a MCU (thing plus esp32 s2), a dual-port shield and a gps (zed-f9r or f9p)

![IMG_4499|666x500]
(upload://tQ3fzYsK2G6Pw714WhYfaaky8E3.jpeg)

[PaulZC]

Thank you Dan,

If possible, please share the schematic and gerbers for your carrier board, so we can check the SPI connections. If you can’t share, please check you have all the POCI=CIPO=MISO signals connected together; and all the PICO=COPI=MOSI signals.

For SPI, you need to make sure that each device on the bus is powered and has its chip select pin pulled high. If a device is off, or its chip select is left to float, or - worse - the chip select is low, you will get data corruption. Communication may be impossible.

Please check that you are pulling the correct pin high for the SD chip select. On the ESP32 S2, “A5” is GPIO 5. Is that correct? If you share your schematic and gerbers, we can check.

Also, do be careful with your SPI modes. We have talked previously about SPI modes here.

I hope this helps,
Paul

[clive1]

Don’t most of the ESP32 have 2 or 3 HW mappable UARTs??

[sgrunc_80]

schematics is very simple:
just the Thing Plus ESP32-S2 connected to the other two boards, besides 3V3 and GND also I2C (needed for SD first change to SPI..) and SPI.
also some led on IO11 and IO12 and a button on IO10.
as said this works fine with the ZED-F9R but very bad or almost never with the F9P.
how you see in the code the CS_GPS is IO06 and CS_SD is A5 (you are correct is IO05).
Print ESP32-S2_Thing_Plus.svg

about the SPI lines, how said I only had problem because of the wrong label of the ZED-F9R, but then always connected from ESP32-S2 to GPS

COPI to MOSI
CIPO to MISO
SCK to SCK

but then if the connection are wrong how could we sometimes read anything via SPI?

Honestly I’m more curious to know if you tried multiple times, with different ZED-F9P, you’re SPI test setup and it always worked fine at first. As said by us yet only 1 of 4 are working properly.. maybe you had some batch not properly soldered.

about other mappable HW interface, I know there must be other two (SPI2 and SPI3) available, will maybe check them later, but why aren’t the default working?

[clive1]

Well there are a lot of settings and undocumented keys, so if you have a configuration file you can kitchen sink a whole lot of unhelpful settings into FLASH configuration space. Can make things very sticky. And there are option settings that can also force behavior independently of the pins, like remapping interfaces or disabling.
DSEL has worked for me on factory parts without issue.

[sgrunc_80]

not completely clear on the last Flash configuration part: I personally never modified the one on the ZED-F9P.
then if I first do a firmware update and then set the interface variable in u-center (like asked here for the interfaces) which other flash settings should be wrong? shouldn’t the board/chip work out of the box?
why it is so different (difficult) from the ZED-F9R anyway?

From the beginning I also thought that the problem is more on the U-blox part, but if you all say that your ZED-F9P work with SPI out of the box then is not the case

[clive1]

If you do a firmware update with Chip Erase it should clear settings there.

Otherwise things can be retained there or BBR.

I’m saying that you might have difficulties if you use a Configuration file via uCenter Classic, which can push in a lot of settings that you don’t want and can’t see. This is a situation Paul alludes too. There are methods to suppress DSEL, but I doubt you’ve engaged those.

UARTs tend to be preferable, as they are a more natural why to output data from the receiver without host interaction. Most ESP32 and SAMD devices have several UARTs

[PaulZC]

Hi Dan,

I’m sorry. I don’t understand why you’re having so many problems. If your ESP32S2 works with the ZED-F9R, then it should work equally well with the ZED-F9P. The SPI interface is exactly the same.

To fully understand what is going wrong, you may need to put a logic analyzer on the SPI bus and look at the signals on all four lines.

Just to be clear, the SPI pin order is the same on both the ZED-F9P and ZED-F9R boards. Looking at your photo and going from ‘top’ to ‘bottom’, the ZED-F9P pins are

CS
RX/MOSI
TX/MISO
SCK

The pin order on the ZED-F9R is the same:
CS
The silk says RX/POCI, but the signal is actually RX/PICO
The silk says TX/PICO, but the signal is actually TX/POCI
SCK

With your orange/yellow/green/blue wires, whatever order works for the ZED-F9R, the same order should work with the ZED-F9P. You should not need to swap the PICO/POCI wires between the two versions.

The SPI interface works very well on the RTK Reference Station. That is able to log RAWX and SFRBX at the full 20Hz.

I hope this helps,
Paul

[sgrunc_80]

sorry don’t know why but first copy of code didn’t inserted the loop part..
anyway here is

//-------------------------------LOOP------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------//
void loop() {
  if (myGNSS.getModuleInfo(1100 * 4)) {
    Serial.println(myGNSS.getModuleName());
  } else {
    Serial.println("myGNSS.getModuleInfo failed");
  }

  delay(2000);
}

then about the SPI connection, how said normally it works fine with every other ZED-F9R used (many), is just that mostly with ZED-F9P isn’t (many).

I’m most curious to know from you or someone else if the Sparkfun RTK (ZED-F9P) board works always (not just one board..) via SPI or there are others with this same problem

[PaulZC]

Sorry Dan (@sgrunc_80 ) - I am out of ideas,

Every ZED-F9P I’ve used on SPI has worked - although some did need a little help if I had used them previously for UART / I2C (as described above).

Did you try adding the CS_SD code - at the start of setup?

pinMode(CS_SD, OUTPUT);
digitalWrite(CS_SD, HIGH);

Best,
Paul

[sgrunc_80]

Hi, Paul
the CS_SD definition doesn’t change anything.
You then acknowledge that there is some strange behavior about the SPI with the board. As info the boards (at least last two) where used directly on SPI first, so don’t know why should have any problem given by the usage of I2C..
do you test each of your produced board?

anyway last effort:
could you please share you’re simplest example on which an SPI connection with ZED-F9P ( SparkFun GPS-RTK) should work?
the minimum needed with just a Thing Plus MCU board like the ESP32-S2 (Sparkfun WRL-17743).
The direct connections, e.g.

DSEL soldered on GPS-RTK

(MCU) - (GPS RTK)

GND–>GND,
3V3 → 3V3 and
? → CS
COPI → RX/MOSI
CIPO → TX/MISO
SCK → SCK

then your code.
maybe a config file of the ZED-F9P if is possible to load it into via U-Center..

Thanks

[PaulZC]

Hi Dan (@sgrunc_80 ),

“the CS_SD definition doesn’t change anything.”. OK. Thank you for trying that.

“do you test each of your produced board?” Yes, of course. But, as far as I am aware, we don’t test SPI specifically. Only I2C and UART1 - which share the same pins.

SPI should “just work”. I really don’t understand why you’re having so many difficulties. The RTK Reference Station works well, we don’t do anything ‘special’ to get SPI operational.

Please follow this link for our simplest SPI example - using v3 of the library. Please note that the example disables NMEA output on SPI, leaving only UBX enabled.

I don’t have an ESP32S2 board here, so I can’t fully replicate your setup. But I have tested this example many times on other boards, standard ESP32 (usually the “SparkFun Thing Plus C”) included.

I rarely use u-center configuration files. I prefer to set the module back to its defaults using UBX-CFG-CFG over USB, and let the library code take it from there.

Your pin connections are correct. The F9P breakouts have an on-board 3.3V regulator, so you can instead link 5V → 5V to provide power. But 3V3 → 3V3 works too.

Please double check that you are using the latest Espressif ESP32 Arduino board package and have selected “SparkFun ESP32-S2 Thing Plus” as the board in the Arduino IDE. The SPI pins vary from board to board, so it is important you select the correct one.

Testing here today, using an old ZED-F9P board with no back-up battery, and the Thing Plus C:

I was using the board yesterday, using the I2C interface.
Today, I have soldered the DSEL jumper, and nothing else.
Running that example, it fails the first time:

I connect u-center to the GNSS over USB.
Looking at UBX-MON-COMMS, I can see that it is attempting to use UART1 even though the DSEL jumper is soldered. I click “Poll” a few times, the UART1 counts are increasing.

I use UBX-CFG-CFG to “Revert to default configuration”, clicking “send” to apply.

I left the ESP32 code example running while I did this and now:

In MON-COMMS, the UART1 counts are frozen and now the SPI counts are increasing:

I hope this helps,
Paul

[sgrunc_80]

Hi Paul

thank you for the documented reply, I finally got some better results on most of problematic boards but still noticing some errors.
In the end I see one board working only when I solder the wires (the other worked well with just the dupont connectors..), but what mostly changed the results is switching from 3V3 to 5V!

anyway still have to debug everything but I see they can work, but the ZED-F9R were much easyer.

Thanks

[PaulZC]

Thanks for the update Dan - glad you got it ~working,

Best,
Paul