Artemis OpenLog + Sparkfun GNSS + ArduinoBLE getting a stack overflow

Hi, I’m stuck on the sparkfun GNSS library version 2.0.15 (currently the library is at 2.2.8). I don’t know what version of the GNSS library exactly causes the issue, but I’ve tried a few releases and it just takes a long time to narrow it down. What I can do that always causes the problem is use the GNSS autoPVT in callback mode, while simultaneously writing to a BLE characteristic once a second and after about 15 seconds with the latest GNSS library it will crash with an mbed OS stack overflow. If I change the GNSS library back to 2.0.15 it works great.

Here’s the combination of versions that gets the stack overflow error:

Arduino Apollo3 board version 2.2.1

ArduinoBLE library version 1.2.2

Sparkfun ublox GNSS Arduino library version 2.2.8

The same code (apart from the required change to the GNSS library to use the ublox struct pointer) works fine with these versions:

Arduino Apollo3 board version 2.2.1

ArduinoBLE library version 1.2.2

Sparkfun ublox GNSS Arduino library version 2.0.15

I’m planning to create a tiny arduino sketch that demonstrates the problem, but it is a pretty big effort and maybe you have some ideas on why or what I should try? There seems to be a lot of great improvements to the GNSS library that I want to try and take advantage of. We really get pretty good results from 2.0.15 version of the library, but occasionally the GNSS module won’t respond to commands to setNavigationFrequency() and gets locked up and I wondered if newer versions fix these rare issues.

Thanks

While I can’t answer this, cross-posting this in the github under “issues” https://github.com/sparkfun/SparkFun_u- … ary/issues might get the ball rollin’

Hopefully someone with similar past experience with this same issue will pop in and shed some light on the subject (or, if you make any progress via github, try and post the results here!)

Hi Richard (@ricozinn),

Thanks for reporting this.

I’ve opened an issue for this on GitHub. Your observations made me wonder if the library has a memory leak, depending on how you create and use the SFE_UBLOX_GNSS class. Turns out, it has! Head on over to GitHub to join the fun:

https://github.com/sparkfun/SparkFun_u- … issues/135

Best wishes,

Paul

Hey Paul, thanks again for your quick help yesterday. I created a minimal sketch that exhibits the stack overflow problem and hopefully described it all well here:

https://github.com/sparkfun/SparkFun_u- … issues/138

I’m still seeing the issue on 2.2.9, in fact since I never stop using the GNSS module I don’t think your deconstructor change you added would ever have a chance to get called the way I’m using it.

Best,

Richard