Unable to start continuous location!

[mos216]

Hello,

Currently, trying to get the sample (loc_cell_gnss_continues working but so far no luck. Here below the output log

+UUSTATUS: READY AT AT

OK U_CELL_PWR: powering on, module is already on. ATE0

OK AT+CMEE=2

OK AT+UDCONF=1,0

OK ATI9

02.00,A01.40

OK AT&C1

OK AT&D0

OK AT&K0

OK AT+UPSV=4,1300

OK AT+UGPRF?

+UGPRF:2,0,""

OK AT+CFUN=4

OK Opened cellular device with return code 0. Bringing up GNSS... U_PORT_BOARD_CFG: using GNSS network configuration associated with CELLULAR device "cfg-device-cellular" from the device tree, GNSS module-type 2, device-pin-pwr -1, device-pin-data-ready -1. AT+CMUX=0,0,,128

OK ATE0

OK AT+CMEE=2

OK U_GNSS: initialising with ENABLE_POWER pin not connected, transport type AT. ATI

LENA-R8001M10-00C-00

OK AT+UGIND=1

OK AT+UGPS?

+UGPS: 0,0,0

OK ATI

LENA-R8001M10-00C-00

OK AT+UGPS=1,15,295

OK Starting continuous location. Unable to start continuous location! [-4]Taking down GNSS...

+UUGIND: 0,295 AT+UGPS?

+UGPS: 1,0,0

OK AT+UGPS=0

OK U_CELL_PWR: powering off with AT command. AT+UPSV=0

OK AT+CPWROFF

+CPOF: MS OFF

OK

+UUGIND: 1,9

+UUGIND: 8,9

[RobMeades]

Apologies, I had forgotten the conversation we had only a week ago in #241 where it was clear that you are using LENA-R8 and trying to address the M10 GNSS chip inside the LENA-R8 module.

As indicated in my most recent post on #248, and as I think you have already concluded, for LENA-R8 it will be much simpler for you to access the internal GNSS chip via the dedicated/separate tx_gnss/rx_gnss pins provided on the module; while you could access the internal GNSS chip via the cellular device you would get into the problems we saw in #241 with UPOS interference and continuous location would, unfortunately, never work: it relies on a stream of data from the GNSS device, it can never work with the polled AT+UGUBX mechanism, which is the only way that LENA-R8 allows the AT (i.e. cellular) interface access to the internal GNSS chip. I will add a note to the main_loc_gnss_cell_continuous.c example that it will not work for a LENA-R8xxxM10 module to avoid further confusion.

So, to use continuous location with a GNSS chip connected via the TXD_GNSS/RXD_GNSS pins you would connect-up another UART of your MCU to those pins and then follow the main_loc_gnss_continuous.c example, i.e. the pattern for a dedicated GNSS device, not a GNSS chip inside a cellular module (i.e. we are ignoring the fact that it is inside the cellular module, it is just a GNSS device as far as ubxlib is concerned, the LENA-R8 HW is apparently designed to work that way). The device configuration you specify would be for a GNSS device and, in your Zephyr device configuration for the GNSS device, you would tell ubxlib to use the UART HW block that is connected to the TXD_GNSS/RXD_GNSS pins, baud rate as appropriate for the M10 device (which I think is probably 9600, the default, anyway, but please check).

Apologies that this is so confusing, it is just a peculiarity of LENA-R8 I'm afraid.

[RobMeades]

Documentation updated in commit addf595e277de3cd47ac5b239c7d5ced8bb29346.

[mos216]

Hi Rob, thanks for explanation.

I tried to manipulate the gnss modem using tx_gnss/rx_gnss directly but no response. I see data on the tx_gnss of the modem by oscilloscope but it doesn't respond to the mcu host. it keeps sending positioning data after hot fix frequently seems like.

U_PORT_BOARD_CFG: using GNSS device "cfg-device-gnss" from the device tree, module-type 2 with pin-enable-power 38 (0x26), pin-data-ready -1 (0xffffffff)... U_PORT_BOARD_CFG: ...GNSS on UART 1, uart-baud-rate 9600. U_GNSS: initializing with ENABLE_POWER pin 38 (0x26), set to 1 to power on GNSS, transport type UART. U_GNSS: sent command b5 62 0a 06 00 00 10 3a. Opened device with return code -8. Unable to bring up the device!

Do I need to enable something using AT command to get this one work. and is there a way to check which baudrate this device is working. I tried multiple baudrates but still no success.

[RobMeades]

Hmmm, I don't actually have a LENA-R8xxxM10 myself to try this out with.

Just to confirm, you have removed the uNetworkInterfaceUp(devHandle, U_NETWORK_TYPE_GNSS, &gNetworkCfg) line from your code; that would cause the cellular bit of the module to start talking to the GNSS chip and might confuse it.

As I'm sure you've read, the integration manual just says:

1.17.1 GNSS UART interface

LENA-R8001M10 modules supports a 1.8 V UART interface consisting of the RXD_GNSS data input line and the TXD_GNSS data output line, directly connected to the internal u-blox M10 GNSS chipset (as is illustrated in Figure 2).

The GNSS UART can be used as serial interface for direct communication between the internal u-blox M10 GNSS chipset and an external host.

The GNSS UART interface supports configurable baud rates. The default baud rate is 38,400 bit/s, with 8N1 (8 data bits, no parity, 1 stop bit) default frame format.

Neither handshaking signals nor hardware flow control signals are available in the UART interface.

Was 38,400 one of the baud rates you tried?

[mos216]

Hi Rob,

sorry is my bad. I didn't notice the default baud-rate in the integration manual.

But do we need to remove this line (uNetworkInterfaceUp) from Gnss initialization ? bc now with a standalone gnss, Cell and Gnss have their separate initialization functions, so ubxlib will have two instances, right?

Another question, since in Zephyr we are using dts , how can we specify which device (GNSS or CELL) has to be opened when calling uDeviceOpen, since the first parameter is null.

[RobMeades]

But do we need to remove this line (uNetworkInterfaceUp) from Gnss initialization ? bc now with a standalone gnss, Cell and Gnss have their separate initialization functions, so ubxlib will have two instances, right?

Apologies, I did not explain well: what I meant was to remove the uNetworkInterfaceUp() line for GNSS where the cellular handle is being passed in as devHandle. You should keep the uNetworkInterfaceUp() line for GNSS where the GNSS handle is being passed in.

Another question, since in Zephyr we are using dts , how can we specify which device (GNSS or CELL) has to be opened when calling uDeviceOpen, since the first parameter is null.

See fourth bullet point here: if you have both a cellular and a GNSS device in your device tree then you do need to have a uDeviceCfg_t structure that you pass to uDeviceOpen() but you only need to populate the uDeviceType_t member of that structure; with U_DEVICE_TYPE_CELL for the uDeviceCfg_t structure you pass when opening the cellular device and U_DEVICE_TYPE_GNSS for the uDeviceCfg_t structure you pass when opening the GNSS device.

Then the ubxlib code is able to tell which is which. A bit of a waste I know but it should be a const structure, so only a small waste of flash.

[mos216]

Hi Rob, thanks for the info and explanation. I built a sample where first uDeviceOpen is called for CELL device and after that initializing mqtt stack and subscribing to a topic. In the same sample, I initialized GNSS as a separate modem, starting again with calling uDeviceOpen for GNSS (in the same sample), and after that calling uLocationGetContinuousStart for permanent looking for location fix. so afterwards we have a one sample where CeLL is subscribing to mqtt topic and gnss is working continuously for getlocation. However, when a message is published to the topic where cell is subscribing to, a message is received successfully but for somehow hardfault error occurs and crash the whole application. but when I stop gnss from looking for location, then everything works fine. Actually debugging this issue is little bit complex in zephyr bc a lot of routins participating behind scene and I'm not so much families how zephyr stack is implemented in ubxlib but there is a relation or some shared resources when two devices with different types are initialized in same firmware. Could you guide me or give some hints for this issue?

here is the fault

[00:00:35.997,680] os: USAGE FAULT [00:00:35.997,711] os: Illegal load of EXC_RETURN into PC [00:00:35.997,741] os: r0/a1: 0x00000002 r1/a2: 0x00050ddb r2/a3: 0xfffffffe [00:00:35.997,741] os: r3/a4: 0x0099b000 r12/ip: 0x00054fb0 r14/lr: 0x00054fb1 [00:00:35.997,772] os: xpsr: 0x00027600

[RobMeades]

Replaying what you say above, the action of receiving an MQTT message causes a crash but that crash goes away if you don't call uLocationGetContinuousStart()?

there is a relation or some shared resources when two devices with different types are initialized in same firmware.

No, there is no relation between the two, they will be using different UARTs and completely different device instances. Provided you aren't doing very much from any callback functions you shouldn't have a stack problem as our default stack allocations are typically over-generous.

Obviously you now have two device handles, so it is worth checking that the right one is being passed to the right functions. Our general debug hints can be found here, but for your specific case I would start by looking in the .map file that your Zephyr build directory contains to see which function your program counter is in when the crash occurs. Only thing is, I can't see a program counter value in that dump of usage fault data, which is strange; was there anything else printed out after that?

I'm not familiar with the Zephyr usage fault information but I would guess that the s[] values are a stack dump and one or more of those values may be function addresses placed on the stack; not sure where you have RAM and flash mapped to but maybe you can tell which is which: for instance, is 0x000277c8 (the zeroth stack entry) in flash and, if so, can you see from the .map file which function it is in (i.e. search for 0x000277, or maybe 0x000276 in the .map file and see if you can narrow-down which function it might be in).

Going back to your description, I would ignore the fact that not calling uLocationGetContinuousStart() makes the problem go away, that could be a side-effect. If receiving an MQTT message causes a crash then you have a good, concrete, repeatable fault situation, which is very useful, concentrate on finding out as much about that as possible.

[mos216]

Hi Rob, after debugging it, I figured out that the stack size of the GNSS thread was small in the main file. after increasing the stack size everything started to work fine so far

but thank you for the explanation about using .map file , it was helpful

[RobMeades]

Excellent!

[RobMeades]

I will close this one now since this part, at least, seems to be working for you. Please feel free to re-open if that is not the case.