Problems with the UBLOX's connectivity

[Victor Lucio]

I was trying to connect my cellphone tu the ublox modulo for sends at commands from my cell, in the main program of the micro I've the next lines for turn on the ublox module:

nrf_gpio_cfg_output(UBLOX_RST_PIN);//activar buffer del modem
nrf_gpio_cfg_output(UBLOX_PWR_PIN);//activar buffer del modem

uart_init();
nrf_gpio_pin_set(UBLOX_RST_PIN);
nrf_gpio_pin_set(UBLOX_PWR_PIN);

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

The error happens after nrf_"gpio_pin_clear(UBLOX_PWR_PIN);",  but that meant that the module did not respond to the at commands and sometimes it's not connect. . For this reason I tried in several ways to solve it and the only thing that works for me is that in the main program I only put the lines until before the delay that I mentioned that I was wrong, in this way to turn on the oblox module for cellular connectivity I must pressed the key.

Now, when I run the program and load it into the terminal, everything goes well until the key is pressed, it shows me the error and the module is restarted(This is where the error occurs and in my boron the RGB LED lights up implying that the entire micro is being completely restarted.), but the connectivity is correct. If I press the button again, other error does not occur and the module doesn't restarted. In other words, the error only happens the first time I press the key.

The new error is this:

[NRF_ERROR_DATA_SIZE] in APP_ERROR_HANDLER(p_event->data.error_communication);

In this line

case APP_UART_COMMUNICATION_ERROR:
APP_ERROR_HANDLER(p_event->data.error_communication);
break;

[Victor Lucio]

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.

[Victor Lucio]

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

[Einar Thorsrud]

Hi,

Victor Lucio said:

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

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.

[Victor Lucio]

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.  

[Denis Rustak]

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!