Adding UART to gnss or location sample causing crash

Our code is very simple--we took the gnss sample, then added UART (Async API) code to it. Both the gnss sample, and the UART code we added, worked independently. Once we combined them into one project, uart_callback_set fails with return value -88 (ENOTSOCK?), and any attempt of calling uart_tx causes a crash and immediate reboot.

We're testing on an nRF9160DK. We want to get UART working so we can get an nRF9160 to talk to an nRF5340 (to send actual data back and forth; we don't want to use HCI).

We can't figure out what is going on; using UART along with GPS and LTE seems like a common use case, but we've been unable to get it to work. We've scoured all the samples, none of which use both UART Async API and GPS/LTE. We've also scoured the forums, but the closest thing we could find to a solution was this ((+) nRF9160 DK: Offloading Bluetooth Low Energy related tasks to nRF52840 SoC - Software and Protocols - Cellular IoT guides - Nordic DevZone (nordicsemi.com)), which shows how to use UART on the nRF9160 but neglects to combine it with GPS or LTE. Basically, in many hours of searching, we've not been able to find any example of hardware UART being used with GPS and/or LTE.

Could someone take a look at our code (zipped and attached here: https://drive.google.com/file/d/1jiAQgvfnRUXsXfCsIwNH9DN_RnrPmUX7/view?usp=sharing) and see what the issue is? Or point us to a sample that uses hardware UART, GPS, and LTE, if one exists.

Thank you.

Michael

Parents
  • You should be able to debug an unintentional reboots in a system. The general idea is to find the context that causes the reboot (FATAL error/ hardfault/ intentional application soft reset). Without knowing the context in which the system rebooted, it is hard to debug further. Have you enabled appropriate logging? If yes, then can you show us the logs to see if there is any information that is flushed there that gives a hint of the context of the reboot.

Reply
  • You should be able to debug an unintentional reboots in a system. The general idea is to find the context that causes the reboot (FATAL error/ hardfault/ intentional application soft reset). Without knowing the context in which the system rebooted, it is hard to debug further. Have you enabled appropriate logging? If yes, then can you show us the logs to see if there is any information that is flushed there that gives a hint of the context of the reboot.

Children
No Data
Related