Suddenly started getting "data was NOTACKNOWLEDGED (NACK) after 23 msec"

[ricozinn]

Hi, I have board Artemis OpenLog board connected to the NEO-MN9 breakout board (https://www.sparkfun.com/products/15712) running version 2.0.15 of the sparkfun GNSS arduino library. I was testing for hours with no problem and then I started getting this (see logs below). Nothing had changed in software so I was suspecting some hardware damage, but under a microscope I can’t see any signs of any kind of issue anywhere (not on the PCB nor on the external enclosure it was in protecting it). Does anyone have an idea of where I should take a closer look? The below is what I get when I issue any command, but this one in particular is trying to set dynamic mode to automotive:

sensor->setDynamicModel(DYN_MODEL_AUTOMOTIVE)

Also, even while this is happening the PPS LED is flashing meaning I think I’ve got a GPS fix, but I can’t get any of the data or issue any commands. Looking at the debug logging below though it looks like part of the response is received, so it makes me think it isn’t just the I2C/QWIIC connection that is failing but possibly something deeper. Anyway, hoping someone with some experience has an idea of what’s going on and can point me in the right direction.

I can swap the GNSS breakout board to another spare I have here and the problem goes away, so I am confident it is a problem on the GNSS breakout board side.

10:11:03.516 → Sending: CLS:CFG ID:0x24 Len: 0x0 Payload:

10:11:03.516 → sendCommand: Waiting for ACK response

10:11:03.516 → checkUbloxI2C: Large packet of 154 bytes received

10:11:03.516 → process: incoming “automatic” message: Class: 0x1 ID: 0x7

10:11:03.550 → Checksum failed: checksumA: 53 checksumB: 91 rollingChecksumA: 181 rollingChecksumB: 91

10:11:03.550 → Incoming: Size: 36 Received: CLS:CFG ID:0x24 Len: 0x24 Payload: FF FF 0 3 0 0 0 0 10 27 0 0 5 0 FA 0 FA 0 64 0 5E 1 0 3C 0 0 0 0 0 0 0 0 0 0 0 0

10:11:03.550 → packetCfg now valid

10:11:03.550 → packetCfg classAndIDmatch

10:11:03.550 → Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 24

10:11:03.550 → packetCfg now valid

10:11:03.550 → packetAck now valid

10:11:03.550 → packetCfg classAndIDmatch

10:11:03.550 → packetAck classAndIDmatch

10:11:03.550 → waitForACKResponse: valid data and valid ACK received after 32 msec

10:11:03.550 →

10:11:03.550 → Sending: CLS:CFG ID:0x24 Len: 0x24 Payload: 1 0 4 3 0 0 0 0 10 27 0 0 5 0 FA 0 FA 0 64 0 5E 1 0 3C 0 0 0 0 0 0 0 0 0 0 0 0

10:11:03.550 → sendCommand: Waiting for ACK response

10:11:03.550 → checkUbloxI2C: Large packet of 138 bytes received

10:11:03.550 → processUBX: NACK received: Requested Class: 0x6 Requested ID: 0x24

10:11:03.583 → Incoming: Size: 2 Received: CLS:ACK ID:0x0 Len: 0x2 Payload: 6 24

10:11:03.583 → packetCfg now valid

10:11:03.583 → packetAck now valid

10:11:03.583 → waitForACKResponse: data was NOTACKNOWLEDGED (NACK) after 23 msec

[PaulZC]

Hi Richard,

I suspect this is pull-up related.

Have you opened the I2C split pads on your NEO board - to disconnect the extra pull-up resistors? We recommend that you do to help minimise bus errors.

Also, you can disable the pull-ups internal to the Artemis too. Please see the OLA GNSS logging example for more details.

https://github.com/sparkfun/OpenLog_Art … ogging.ino

One final tip, please make sure you are using v2.2.0 of the Apollo3 (Artemis) boards in Arduino. V2.1.2 had some issues with I2C communication with devices like the NEO that clock stretch.

Best wishes,

Paul

[ricozinn]

Thanks for the info! I am running 2.1.1 of the Apollo3 board, so I’ll try updating that. I had already cut the traces on the pull-up resistors on the breakout board and disabled internal pull-ups on the artemis before this problem started happening. Also, I went from 100% success rate, to 100% failure rate with communications to the GNSS board inside of a one hour period of testing with no signs of damage to anything and for sure no firmware changes. So, I’m skeptical it is any of these.

The debugging logs are hard for me to follow, but it appears this is the line to focus on:

10:11:03.550 → Checksum failed: checksumA: 53 checksumB: 91 rollingChecksumA: 181 rollingChecksumB: 91

so probably garbled data on the i2c bus? Or could anything else you can imagine be causing this?

[PaulZC]

The I2C checksum errors are usually a clear indication of bus errors caused by the pull-ups not being correct. V2.1.2 of Apollo3 exhibited lots of these errors but all is well with 2.2.0.

If you have access to an oscilloscope, had a look at the clock and data signals on your good and bad boards. I suspect you’ll see slow rising edges on one but not the other?

[ricozinn]

I upgraded to 2.2.0 and am still seeing the same issue. I don’t have a scope at the office but can get to one in the next few days to see if the edges are slow rising. Can you think of anything else that could be causing this though?

Actually, looking at it a little closer I’m not seeing the checksum error. And the first part of the messages does get a valid ACK, it’s just the second part that doesn’t.

13:21:36.962 → Sending: CLS:CFG ID:0x24 Len: 0x0 Payload:

13:21:36.962 → sendCommand: Waiting for ACK response

13:21:36.962 → checkUbloxI2C: Large packet of 154 bytes received

13:21:36.962 → process: incoming “automatic” message: Class: 0x1 ID: 0x7

13:21:36.997 → processUBX: incoming “automatic” message: Class: 0x1 ID: 0x7

13:21:36.997 → Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: 20 B9 8 14 E6 7 1 C 15 15 26 37 64 0 0 0 BF 19 0 0 3 1 EB 8 FB 52 2A BA D3 2B F8 13 37 2E 3 0 B2 AD 3 0 72 27 0 0 BB 8E 0 0 EF FF FF FF FD FF FF FF F5 FF FF FF 11 0 0 0 0 0 0 0 60 1 0 0 DC 6B 9C 0 CC 1 0 0 EE 13 4F 2F 0 0 0 0 0 0 0 0

13:21:36.997 → packetCfg now valid

13:21:36.997 → Incoming: Size: 36 Received: CLS:CFG ID:0x24 Len: 0x24 Payload: FF FF 0 3 0 0 0 0 10 27 0 0 5 0 FA 0 FA 0 64 0 5E 1 0 3C 0 0 0 0 0 0 0 0 0 0 0 0

13:21:36.997 → packetCfg now valid

13:21:36.997 → packetCfg classAndIDmatch

13:21:36.997 → Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 24

13:21:36.997 → packetCfg now valid

13:21:36.997 → packetAck now valid

13:21:36.997 → packetCfg classAndIDmatch

13:21:36.997 → packetAck classAndIDmatch

13:21:36.997 → waitForACKResponse: valid data and valid ACK received after 44 msec

13:21:36.997 →

13:21:36.997 → Sending: CLS:CFG ID:0x24 Len: 0x24 Payload: 1 0 4 3 0 0 0 0 10 27 0 0 5 0 FA 0 FA 0 64 0 5E 1 0 3C 0 0 0 0 0 0 0 0 0 0 0 0

13:21:37.031 → sendCommand: Waiting for ACK response

13:21:37.031 → checkUbloxI2C: Reading 10 bytes

13:21:37.031 → processUBX: NACK received: Requested Class: 0x6 Requested ID: 0x24

13:21:37.031 → Incoming: Size: 2 Received: CLS:ACK ID:0x0 Len: 0x2 Payload: 6 24

13:21:37.031 → packetCfg now valid

13:21:37.031 → packetAck now valid

13:21:37.031 → waitForACKResponse: data was NOTACKNOWLEDGED (NACK) after 9 msec

[ricozinn]

I also tried updating from the GNSS library version 2.0.15 to the latest 2.1.5 release and while compiling I get this error:

OpenLog_Artemis.ino.cpp:(.text._Z17beginQwiicDevicesv+0xac): undefined reference to `SFE_UBLOX_GNSS::begin(arduino::MbedI2C&, unsigned char, unsigned short, bool)'

/Users/richardzinn/Library/Arduino15/packages/SparkFun/tools/arm-none-eabi-gcc/8-2018-q4-major/bin/arm-none-eabi-gcc -T/Users/richardzinn/Library/Arduino15/packages/SparkFun/hardware/apollo3/2.2.0/tools/uploaders/svl/0x10000.ld -Wl,-Map,/var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/OpenLog_Artemis.ino.map -o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/OpenLog_Artemis.ino.axf /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/sketch/OpenLog_Artemis.ino.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/BLEAdvertisingData.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/BLECharacteristic.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/BLEDescriptor.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/BLEDevice.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/BLEService.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/BLEStringCharacteristic.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/BLETypedCharacteristics.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/local/BLELocalAttribute.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/local/BLELocalCharacteristic.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/local/BLELocalDescriptor.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/local/BLELocalDevice.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/local/BLELocalService.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/remote/BLERemoteAttribute.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/remote/BLERemoteCharacteristic.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/remote/BLERemoteDescriptor.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/remote/BLERemoteDevice.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/remote/BLERemoteService.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/utility/ATT.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/utility/BLEUuid.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/utility/GAP.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/utility/GATT.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/utility/HCI.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/utility/HCICordioTransport.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/utility/HCIUartTransport.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/ArduinoBLE/utility/L2CAPSignaling.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/Wire/Wire.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/EEPROM/EEPROM.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SPI/SPI.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FreeStack.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/MinimumSerial.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/ExFatLib/ExFatDbg.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/ExFatLib/ExFatFile.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/ExFatLib/ExFatFilePrint.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/ExFatLib/ExFatFileWrite.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/ExFatLib/ExFatFormatter.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/ExFatLib/ExFatName.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/ExFatLib/ExFatPartition.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/ExFatLib/ExFatVolume.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FatLib/FatDbg.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FatLib/FatFile.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FatLib/FatFileLFN.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FatLib/FatFilePrint.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FatLib/FatFileSFN.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FatLib/FatFormatter.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FatLib/FatName.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FatLib/FatPartition.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FatLib/FatVolume.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FsLib/FsFile.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FsLib/FsNew.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/FsLib/FsVolume.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SdCard/SdCardInfo.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SdCard/SdSpiCard.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SdCard/SdioTeensy.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SpiDriver/SdSpiArtemis.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SpiDriver/SdSpiChipSelect.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SpiDriver/SdSpiDue.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SpiDriver/SdSpiESP.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SpiDriver/SdSpiParticle.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SpiDriver/SdSpiSTM32.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SpiDriver/SdSpiSTM32Core.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/SpiDriver/SdSpiTeensy3.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/common/FmtNumber.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/common/FsCache.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/common/FsDateTime.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/common/FsName.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/common/FsStructs.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/common/FsUtf.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/common/upcase.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/iostream/StdioStream.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/iostream/StreamBaseClass.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/iostream/istream.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SdFat/iostream/ostream.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/RTC/RTC.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SparkFun_9DoF_IMU_Breakout_-_ICM_20948_-_Arduino_Library/ICM_20948.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SparkFun_9DoF_IMU_Breakout_-_ICM_20948_-_Arduino_Library/util/ICM_20948_C.c.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/libraries/SparkFun_u-blox_GNSS_Arduino_Library/SparkFun_u-blox_GNSS_Arduino_Library.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/core/config/pins.cpp.o /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/core/variant.cpp.o -Wl,--whole-archive /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_cache_693598/core/core_96a41b4031e7f210efaeee2e35b1b74f.a -Wl,--no-whole-archive -Wl,--whole-archive /Users/richardzinn/Library/Arduino15/packages/SparkFun/hardware/apollo3/2.2.0/variants/SFE_ARTEMIS_ATP/mbed/libmbed-os.a -Wl,--no-whole-archive -Wl,--whole-archive /Users/richardzinn/Library/Arduino15/packages/SparkFun/hardware/apollo3/2.2.0/cores/mbed-os/targets/TARGET_Ambiq_Micro/TARGET_Apollo3/sdk/CMSIS/ARM/Lib/ARM/libarm_cortexM4lf_math.a -Wl,--no-whole-archive @/Users/richardzinn/Library/Arduino15/packages/SparkFun/hardware/apollo3/2.2.0/variants/SFE_ARTEMIS_ATP/mbed/.ld-flags --specs=nano.specs --specs=nosys.specs -lsupc++ -lstdc++ -lm -DARDUINO=10815 -DARDUINO_APOLLO3_SFE_ARTEMIS_ATP -DARDUINO_ARCH_MBED -DARDUINO_ARCH_APOLLO3 -DMBED_NO_GLOBAL_USING_DIRECTIVE -DCORDIO_ZERO_COPY_HCI @/Users/richardzinn/Library/Arduino15/packages/SparkFun/hardware/apollo3/2.2.0/variants/SFE_ARTEMIS_ATP/mbed/.ld-symbols
/Users/richardzinn/Library/Arduino15/packages/SparkFun/tools/arm-none-eabi-gcc/8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld: /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/sketch/OpenLog_Artemis.ino.cpp.o: in function `testDevice(unsigned char, unsigned char, unsigned char) [clone .part.23]':
OpenLog_Artemis.ino.cpp:(.text._Z10testDevicehhh.part.23+0x30): [b]undefined reference to `SFE_UBLOX_GNSS::begin(arduino::MbedI2C&, unsigned char, unsigned short, bool)'[/b]
/Users/richardzinn/Library/Arduino15/packages/SparkFun/tools/arm-none-eabi-gcc/8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld: /var/folders/bx/py22vn8n0dxf0d6cf9s_26gr0000gq/T/arduino_build_60772/sketch/OpenLog_Artemis.ino.cpp.o: in function `beginQwiicDevices()':
OpenLog_Artemis.ino.cpp:(.text._Z17beginQwiicDevicesv+0xac): undefined reference to `SFE_UBLOX_GNSS::begin(arduino::MbedI2C&, unsigned char, unsigned short, bool)'
collect2: error: ld returned 1 exit status
Using library ArduinoBLE at version 1.2.1 in folder: /Users/richardzinn/Documents/Arduino/libraries/ArduinoBLE 
Using library Wire at version 2.0.0 in folder: /Users/richardzinn/Library/Arduino15/packages/SparkFun/hardware/apollo3/2.2.0/libraries/Wire 
Using library EEPROM at version 2.0.0 in folder: /Users/richardzinn/Library/Arduino15/packages/SparkFun/hardware/apollo3/2.2.0/libraries/EEPROM 
Using library SPI at version 2.0.0 in folder: /Users/richardzinn/Library/Arduino15/packages/SparkFun/hardware/apollo3/2.2.0/libraries/SPI 
Using library SdFat at version 2.1.0 in folder: /Users/richardzinn/Documents/Arduino/libraries/SdFat 
Using library RTC at version 2.0.0 in folder: /Users/richardzinn/Library/Arduino15/packages/SparkFun/hardware/apollo3/2.2.0/libraries/RTC 
Using library SparkFun_9DoF_IMU_Breakout_-_ICM_20948_-_Arduino_Library at version 1.2.6 in folder: /Users/richardzinn/Documents/Arduino/libraries/SparkFun_9DoF_IMU_Breakout_-_ICM_20948_-_Arduino_Library 
Using library SparkFun_u-blox_GNSS_Arduino_Library at version 2.1.5 in folder: /Users/richardzinn/Documents/Arduino/libraries/SparkFun_u-blox_GNSS_Arduino_Library 
exit status 1

In general I have a hard time knowing what library versions are tested together. What GNSS library version would you recommend at this moment? I was on 2.0.15. Thanks

[PaulZC]

Humm… The data looks clean. No checksum errors. But when you try to change the dynamic model to 4 (automotive), the request is NACK’d (negative acknowledgment).

I haven’t seen that before…

Are you trying to do a survey-in or anything similar? Something that would require you to be in stationary mode?

There is no reason not to use the latest GNSS library. That new error is probably due to upgrading to v2.2 of Apollo3. But I haven’t seen that before either.

Please make sure you have the Artemis ATP (All The Pins) selected as the board.

But I’m confused. Are you trying to compile your own code, one of our examples, or the actual OLA firmware?

[ricozinn]

I do have that board selected:

And yes, it is very similar code to the latest OpenLog_Artemis example project. I’m using your Arduino IDE and have it all set up pretty normal.

I can start a new sample project using exactly one of your examples using Apollo 2.2 and the 2.1.5 of the GNSS library and see if I get the same thing. I’ll try that next.

[ricozinn]

BTW, closing arduino and re-opening it fixed the compile problem. I think I notice that reopening the arduino IDE acts similar to a “clean”. So I can now successfully build the project again with the latest versions of the board 2.2 and the GNSS library 2.1.5 but the original problem doesn’t go away. I’ll try other tests tomorrow (like one of your example projects) and see how that works. Maybe though there is a factory reset option I can run on the breakout board?

[PaulZC]

The GNSS library has many built-in examples. Open File \ Examples \ SparkFun u-blox GNSS Arduino Library in the Arduino IDE to see them.

But, on the OpenLog Artemis there are extra steps you need to add to enable power for the Qwiic port etc…

My advice is to start with the dedicated OLA GNSS Logging example:

https://github.com/sparkfun/OpenLog_Art … ogging.ino

And uncomment this line to reset the module:

https://github.com/sparkfun/OpenLog_Art … g.ino#L218

[ricozinn]

Hah, I was trying to adapt the Example1 AutoPVT and had it all about right except I was trying to pass the second param in at the red circled area in the image below (i2c address) and that was my problem… Removing that param like in the example you pointed me to worked. You saved me a bunch of time with that help - but if I had looked at your comment sooner it would have saved me a bunch more

So this is really helpful to see it working and printing out lat/long coordinates. But, after digging in a little more it is just working in its default configuration, all of the set commands are still failing. So if for example I check the return status of any of my configuration commands they are all false

if(!myGNSS.setNavigationFrequency(2)){ //Produce two solutions per second
    Serial.println(F("u-blox GNSS can't set nav freq to 2"));
    while(1);
  }

If I ignore that the commands are failing then I do get the autoPVT messages and the coordinates are valid for where I’m at. My own software tries to use the callback method and that command is also getting rejected so I never see the callbacks I was expecting:

sensor->setAutoPVTcallback(&gnssPVTdata);

I have also since tried the factory reset and it didn’t help things.

Looks like my problem is isolated to any of the set commands. Any idea what that could be?

[PaulZC]

Try 100kHz - as per the advice here:

https://github.com/sparkfun/SparkFun_u- … 2c-support

[ricozinn]

I had tried that (just tried it again now) and with the same results.

qwiic.setClock(AM_HAL_IOM_100KHZ);

Here’s my full setup function below. It stops at the first while(1) in side the return status check of the setNavFrequency call. If I let it leave that loop it gets stuck in the next one too and so on. I’m going to try another/better microscope and see if I can see broken traces or something on there. The only weird things that happened when it stopped working is these two things:

1. The antenna cable was clipped during the test at some point, but a clean cut and nothing was getting shorted anywhere. So to me this seems like unscrewing the antenna… I don’t think this should break anything, but maybe?

2. The device was battery powered and was left on until it hit its low-voltage and then it would have powered itself off (same code that is in the OpenLog Artemis example sketch). When I started it up the next day it had to be connected to power to charge a little and then I started seeing this problem. Maybe there is a bug in that code and it had a brown-out that damaged something?

void setup()
{
  Serial.begin(115200);
  while (!Serial); //Wait for user to open terminal
  Serial.println("SparkFun u-blox Example");


  pinMode(18, OUTPUT);
  pin_config(PinName(18), g_AM_HAL_GPIO_OUTPUT); // Make sure the pin does actually get re-configured
  pinMode(18, OUTPUT);
  digitalWrite(18, HIGH);
  delay(500);
  qwiic.begin();
  
  am_hal_gpio_pincfg_t sclPinCfg = g_AM_BSP_GPIO_IOM1_SCL;
  am_hal_gpio_pincfg_t sdaPinCfg = g_AM_BSP_GPIO_IOM1_SDA;
  sclPinCfg.ePullup = AM_HAL_GPIO_PIN_PULLUP_NONE; // No pull-ups
  sdaPinCfg.ePullup = AM_HAL_GPIO_PIN_PULLUP_NONE;
  pin_config(PinName(8), sclPinCfg);
  pin_config(PinName(9), sdaPinCfg);
  
  qwiic.setClock(AM_HAL_IOM_100KHZ);
  delay(900);

  if (myGNSS.begin(qwiic) == false) //Connect to the u-blox module using Wire port
  {
    Serial.println(F("u-blox GNSS not detected at default address so freezing"));
    while(1);
  }

  //myGNSS.factoryDefault(); delay(5000);
  myGNSS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise)
  
  if(!myGNSS.setNavigationFrequency(2)){ //Produce two solutions per second
    Serial.println(F("u-blox GNSS can't set nav freq to 2"));
    while(1);
  }
  if(!myGNSS.setAutoPVT(true)){//; //Tell the GNSS to "send" each solution
    Serial.println(F("u-blox GNSS can't set AutoPVT"));
    while(1);
  }
  //myGNSS.saveConfiguration(); //Optional: Save the current settings to flash and BBR

  if(!myGNSS.setDynamicModel(DYN_MODEL_AUTOMOTIVE)){
    Serial.println(F("u-blox GNSS can't set dyn model automative"));
    while(1);
  }
}

[PaulZC]

Hi Richard,

I’m out of ideas. It does indeed look like bizarre hardware damage I’ve not seen before.

Best wishes,

Paul

[ricozinn]

I’m going to get the scope out like you mentioned and check the i2c lines to see if they are in fact rising slow or something. I wouldn’t feel so inclined to chase this down so much except we just purchased 30 of these we found on Mouser this week and we’ve been working with Cullen H from your team at the Sparkfun sales office to try and buy another 100 as soon as they can be in stock.

I have another board on my desk that fell off one of the motorcycles we test with and got ran over about 30 times (bare board) and even it still works with a dented RF shield and other obvious signs of misuse. We have so far been really impressed with the manufacturing quality of the PCB. I’m kind of nervous about such a mysterious problem where there’s been no signs of damage. You’ve been tremendously helpful though so far and gone above and beyond what I was ever hoping to get. Can I ask you to give it one more try from a new angle? Maybe I should try re-flashing the ublox firmware? Or is there possibly a tamper resistance feature of the chip to now allow configuration changes to be made that we somehow triggered?

[ricozinn]

Here’s an example from a working device.

Here’s a screenshot of the scope from our device that does the “data was NOTACKNOWLEDGED (NACK)…”:

They both look about the same to me. Does it look like a problem that the SDA line is always low (the top one)? I don’t have any other I2C devices and I’m using your QWIIC library with all the pull-ups removed.

[PaulZC]

Hi Richard,

I think the bottom trace in both images has to be SDA? SCL would be a much more regular square wave during each transfer?

Is there any possibility you have SDA and SCL swapped?

For firmware upgrades, please see:

https://learn.sparkfun.com/tutorials/ho … s-receiver

Best wishes,

Paul

[ricozinn]

Yep… I had the connector off by one. I knew something was wrong there. This is the capture from the device exhibiting the NACK problem. This looks good, right?

[ricozinn]

Here’s where we see the NAK

[PaulZC]

The NAK in your last image is a true I2C bus NAK. It is probably just signifying the end of a write from the Artemis to the u-blox module. That’s very different to the u-blox UBX protocol NACK you see in the debug prints from the library.

There is something weird going on though. The clock signal should not normally be low for a long period - as it is at the very start of your last capture. Unless there is some extreme clock-stretching going on…

Sorry - I really am out of ideas!

Re-flashing the NEO-M9N firmware upgrade may help? Even if you’re just re-flashing the same firmware version, at least you know everything will be set back to the defaults. Details were in my previous post.

All the best,

Paul