Problems with the UBLOX's connectivity

RE: Problems with the UBLOX's connectivity

Denis Rustak — Thu, 27 Feb 2020 17:03:19 GMT

There are a couple of things on how the power pin for this device needs to be driven. Most cell data modules treat the power pin as if it were a user-activated button like what you find on a cell phone -- push-and-release to turn on, push-and-release to turn off.

The SARA-R410M is like that (but particularly bad to be honest). On startup, you should have the reset line and the power pins high (actually, open drain but the Boron has open drain drivers so you can use normal outputs). If coming from a clean/cold start, the R410M will be off. Give it a second or two and then drive the power pin low for *3 seconds*, then bring it back high. That should power the modem on and in the next second or two it should respond to AT commands.

To power it off, repeat the process of driving the power pin low for 3 seconds, then back high/open. This will turn it off.

This gets funky if you reset the processor without power cycling as the modem will still be on and the power-on sequence now turns it *off*. There are different ways to take handle this problem. The Particle Boron has a sense input that detects if the module is already powered up (p0.02 IIRC but check). If you read it and it's high, you know you can skip the power-on sequence.

Once power-on works, you'll still bump into a few issues getting the Boron to work.

The first is that when you power the device on and off, it will generate bad data on the UART lines which cause framing errors for the NRF. The NRF app_uart library does not handle these well. Initializing the uart after power up can help here, as can a call to uart_unit, but the newer serial libraries are a better choice and have nice buffers to boot.

Also, the R410M does not support handshaking but still needs the RTS line grounded so you have to configure the port with HWFC disabled and then ground RTS yourself. Because of this, buffer overflows are something you need to address at the application level. This isn't a big deal if you avoid using the USODL mode and stick to USORD calls when you need to get data.

Finally, the R410M needs to have the DTR pin grounded for it to send URC's to the processor (such as USOCL !). The folks at Particle decided not to do that (wut?) so getting notifications of things like disconnections, new data and the like are needlessly challenging. They also ship older firmware in their modems (units bought 2 months ago have firmware from Feb 2018) so upgrading them isn't a bad idea if you're looking for reliability.

Sorry for the length of this; I wrote it in bouts and it turned into a blog post!

RE: Problems with the UBLOX's connectivity

Victor Lucio — Thu, 27 Feb 2020 13:45:13 GMT

Is that the content of p_event->data.error_communication? If so, this is FRAMING and BREAK in ERRORSRC.

Correct.

Thank you for responding, the error is inmediated and ocurrs in the first 2 seconds since i dowloaded the program in the boron module. That is to say, it happens before communicating with him via bluetooth.

RE: Problems with the UBLOX's connectivity

Einar Thorsrud — Thu, 27 Feb 2020 09:06:36 GMT

Hi,

[quote user="Victor Lucio"]Thank you for responding, the error you referred to is error number 12, that is[/quote]

Is that the content of p_event->data.error_communication? If so, this is FRAMING and BREAK in ERRORSRC.

So the issue as it stands is that you manipulate the LTE device so that it causes problems with the UART communication with the nRF. Unfortunately, I do not have any experience with that device so I am not in a position to suggest more about what happens there. But it seems clear that you need to understand the ublox module better, and make sure that you don't try to communicate with it via UART when it is not ready for it (for instance while it is being reset, and potentially in other times as well.

RE: Problems with the UBLOX's connectivity

Victor Lucio — Thu, 27 Feb 2020 03:35:39 GMT

Sorry for the inconvenience, I am new using these modules.

RE: Problems with the UBLOX's connectivity

Victor Lucio — Wed, 26 Feb 2020 21:06:28 GMT

Thank you for responding, the error you referred to is error number 12, that is

[NRF_ERROR_DATA_SIZE]

Thos happens in the main, in the line:

in APP_ERROR_HANDLER(p_event->data.error_communication);

I have been making a change in the code, in the main of my program I have this(UBLOX_PWR_PIN = Pin16 of nrf),

uart_init();
nrf_gpio_cfg_output(UBLOX_PWR_PIN);
nrf_gpio_pin_set(UBLOX_PWR_PIN);
nrf_delay_ms(200);
nrf_gpio_pin_clear(UBLOX_PWR_PIN);

While if the "mode" button is pressed, I will reset the ublox module.(UBLOX_RST_PIN=Pin12)

case BSP_EVENT_KEY_0:
if (m_conn_handle != BLE_CONN_HANDLE_INVALID)
{
nrf_gpio_cfg_output(UBLOX_RST_PIN);//activar buffer del modem
nrf_gpio_pin_clear(UBLOX_RST_PIN);
nrf_delay_ms(200);
nrf_gpio_pin_set(UBLOX_RST_PIN);
}
break;

The cellular connectivity is now correct but this happens when I first load the program.

It is important to mention that if I reset the ublox module from the "mode" button, no error occurs, but if I reset the boron module from the reset button, the error appears. the error is that the rgb leds of the boron module remain on for about a second, then it goes out and does not happen again.

RE: Problems with the UBLOX's connectivity

Einar Thorsrud — Wed, 26 Feb 2020 08:36:37 GMT

Hi,

I see. So you are working on a Particle Boron, which has a nRF52840 and a U-blox LTE device connected like this (from Boron documentation):

When you do things with the POWER_ON signal and RESET signal things happen in the u-blox module that causes issues with UART communication. You may get some relevant information by checking the error_communication that I asked for. As you snipped from the documentation, that will tell you the reason for the error. In any case, it is clear that the only difference on the nRF side is how it powers on or resets the u-blox module, so you need to look into that to understand what is going on and how it should be fixed. I suggest you contact U-blox about that since it is their product.

If I am understanding you in the wrong way, and your tweaking with the POWER_ON and RESET signal is not the problem, then knowing the error_communication value (which is the ERRORSRC register) is even more relevant. If it is a framing error, which is quite typical, then it could be caused by a clock mismatch. You should make sure to start the HFXO on the nRF side in that case, and similarly choose a high accuracy clock on the u-blox (if not done automatically).

RE: Problems with the UBLOX's connectivity

Victor Lucio — Wed, 26 Feb 2020 03:13:46 GMT

Is the nRF inside the ublox module, or is the nRF one device, and the ublox module another device (which kind of device - what is the model number)?

The module that I'm using is the which shows in the next link docs.particle.io/.../. Ublox module -->sara-r410m-02b.

Is the nRF trying to power-cycle and reset the ublox device?

Indeed, I am restarting and turning on the ublox module from the nRF pins (pin 12 and pin 16).

Do you have UART communication ongoing between the nRF and ublox module?

I'm using bluetooth communication between my cell phone and the Ublox module to send it ar commands

What state is the ublox module in when you get this error?

The error happens in these lines

nrf_gpio_pin_clear(UBLOX_PWR_PIN);
nrf_delay_ms(200);
nrf_gpio_pin_set(UBLOX_PWR_PIN);
I am trying to reset the ublox module to reestablish communication via bluetooth otherwise the communication between my cell phone and the ublox module is not correct (it does not respond to the at commands)
On other hand uart's communication error refers to this:
This field contains the value in the ERRORSRC register for the UART peripheral. The UART_ERRORSRC_x defines from nrf5x_bitfields.h can be used to parse the error code. See also the \nRFXX Series Reference Manual for specification. */

RE: Problems with the UBLOX's connectivity

Einar Thorsrud — Tue, 25 Feb 2020 14:57:56 GMT

Hi,

I am still lacking an understanding of your setup. Please confirm if this is correct and elaborate:

Is the nRF inside the ublox module, or is the nRF one device, and the ublox module another device (which kind of device - what is the model number)?
Is the nRF trying to power-cycle and reset the ublox device?
Do you have UART communication ongoing between the nRF and ublox module?
What state is the ublox module in when you get this error?

Could it be caused by you resetting or in other ways messing with the ublox module when there is active UART communication? The typical reason for getting APP_UART_COMMUNICATION_ERROR is a UART framing error, but you can check error_communication to know more details.

RE: Problems with the UBLOX's connectivity

Victor Lucio — Tue, 25 Feb 2020 02:38:00 GMT

Hi, I want to restart the module because with this I can get cell connectivity without problems. What I do is similar to what is shown in the image.
I have really done tests and it always gives me problems with these lines(specifically the delay)

nrf_gpio_pin_clear(UBLOX_PWR_PIN);
nrf_delay_ms(200);
nrf_gpio_pin_set(UBLOX_PWR_PIN);

, so I would like to be oriented to know if I am activating the cell module correctly.

RE: Problems with the UBLOX's connectivity

Einar Thorsrud — Mon, 24 Feb 2020 13:29:28 GMT

Hi,

It is not clear to me what the GPIO pin toggling has to do with UART. Also, the pin names (UBLOX_PWR_PIN etc.) indicate that you are powering and resetting the Ublox module. Is this another module you are running this code on? Can you elaborate on the setup etc.?