How to add feature to Serial LTE Modem application?

[Alan-Ni]

Hello all,

I'm working on nRF-9160 and nRF-9151. 

What I want to add into SLM application were:

1. Configure to communicate through UART2 since it will be working with external MCU (already solved)
2. Having a power status LED, which turns on as soon as there's power going into SiP, but would turn of while in sleep mode.
3. If not in data-mode, ignore inputs that doesn't start with AT since that probably wasn't messages for 91XX.

I got 9160 running with v2.4.0 SLM application previously, the merge.hex fulfilled 1. and 2., and was provided by distributor.

Now I'm trying to build a merge.hex for 9151 by myself.

For the first one, I've seen the configure page about how to configure to UART2 and get that done.

For the second one, I've also seen a configuration about "CONFIG_SLM_INDICATE_PIN" - Interface GPIO pin to indicate data available or unsolicited event notifications.
It was noted that "This pin is configured to be active low, so it will be high when inactive."
That looks kind of match what I need since it would be high when waiting for data or notifications.
However Its default to set to P0.30, and I'm not sure will any function be impacted if I change the port of this function? ( My LED was on GPIO0)
Plus what was this function normally used? Is it a good method to output that to a LED instead of to somethings input?

And for the third function, my actual problem was I'm short of my MCU output interface, so the UART connecting to nRF91XX was the only interface I could use to print debug message.
However it looks like the SLM application would start analyzing commands no matter if it starts with AT or not, so when I print my own message, it would return ERROR to me and that will trigger my MCU to reset the 91XX.

So....

About function 2 and function 3, are there any suggest ways to implement them?

[Maria Gilje]

Hello,

2. Having a power status LED, which turns on as soon as there's power going into SiP, but would turn of while in sleep mode.

For the second one, I've also seen a configuration about "CONFIG_SLM_INDICATE_PIN" - Interface GPIO pin to indicate data available or unsolicited event notifications.
It was noted that "This pin is configured to be active low, so it will be high when inactive."
That looks kind of match what I need since it would be high when waiting for data or notifications.
However Its default to set to P0.30, and I'm not sure will any function be impacted if I change the port of this function? ( My LED was on GPIO0)

As long as the LED you use is not a high-power LED you should be able to implement this functionality.

Using another pin than P0.30 is fine.

Plus what was this function normally used? Is it a good method to output that to a LED instead of to somethings input?

I am not experienced with the SLM application, so I will forward these questions internally.

Do note that you need to configure an interrupt pin to wake up from the SLM from sleep mode as well.

3. If not in data-mode, ignore inputs that doesn't start with AT since that probably wasn't messages for 91XX.

And for the third function, my actual problem was I'm short of my MCU output interface, so the UART connecting to nRF91XX was the only interface I could use to print debug message.
However it looks like the SLM application would start analyzing commands no matter if it starts with AT or not, so when I print my own message, it would return ERROR to me and that will trigger my MCU to reset the 91XX.

I will also forward this internally.

Please let us know which nRF Connect SDK version you are using. If you haven't started yet, we recommend the latest tagged release (v2.9.0 currently).

Best regards,

Maria

[Alan-Ni]

Hi Maria,

 Thanks for replying!

I've tested to configure the indicate pin to PO.30 and it does lit on the LED (Sleep mode not tested yet).

For the 3rd modify, I'm building v2.7.0 now but it is totally fine to move on to newer version.
Since 9151 only support 2.7.0 or higher version, and in our previous project MCU was coded to communicate with v2.4.0 SLM 9160, so changes are a must anyway.

[Maria Gilje]

Hi Alan-Ni,

Alan-Ni said:

 Thanks for replying!

Happy to!

Plus what was this function normally used? Is it a good method to output that to a LED instead of to somethings input?

The original functionality is that the LED will flash when the device is in sleeping state data is received from the network. When using external MCUs like you are, you connect the indicate pin to the external MCU and use the toggling of the indicate pin to re-enable the UART via the power pin.

The recommendation I got is that when you use the external MCU you should keep the original functionality in the SLM app and duplicate some of the GPIO logic to control the LED.

3. If not in data-mode, ignore inputs that doesn't start with AT since that probably wasn't messages for 91XX.

And for the third function, my actual problem was I'm short of my MCU output interface, so the UART connecting to nRF91XX was the only interface I could use to print debug message.
However it looks like the SLM application would start analyzing commands no matter if it starts with AT or not, so when I print my own message, it would return ERROR to me and that will trigger my MCU to reset the 91XX.

To ignore messages which are not AT commands you need to search for the start of the AT command in slm_at_host.c. You can see how this is done when the goal is to ignore the AT part of the AT-commands here.

This approach will most likely work well when used from the start of the processed loop in cmd_rx_handler. Note that if the debug message includes the start of the AT command, they will not be ignored, so keep in mind the formatting of the debug messages.

Alan-Ni said:

For the 3rd modify, I'm building v2.7.0 now but it is totally fine to move on to newer version.

Using nRF Connect SDK v2.7.0 should be fine. If we see that upgrading further is necessary, we'll let you know. For now it is up to you if you want to switch to v2.9.0 or not.

Alan-Ni said:

Since 9151 only support 2.7.0 or higher version

This is the reason I asked, so it's great to see that you are aware already!

Best regards,

Maria

[Alan-Ni]

Hi Maria Gilje,

I don't quite get the meaning of

"""When using external MCUs like you are, you connect the indicate pin to the external MCU and use the toggling of the indicate pin to re-enable the UART via the power pin"""

Does that means normally one should send power up signal to 91XX through Power pin to wake up the SiP? Or if the external MCU was also in sleep mode should be able to be wake up through this indicate pin?

Also I would like to know how do I implement the recommended duplicate GPIO logic method.
Could that be done by configuring the overlay? Like binding the status of my LED GPIO to that default indicate pin GPIO?

For the debug function, I've read the mentioned part of the code, and saw the code comment saying "We ignore everything before the start of the AT-command.",
It looks like there were some garbage ignoring design already, so I tested again to input some random string and get an ERROR response as expect.
However I checked the comment again and notice it says "before the start of the AT command", so I guess a starting point of AT must exist to avoid getting that ERROR.
I tested again, I append an AT at the end of the random string, and this time I get an OK instead of ERROR.
So... that totally is a problem solved to me, adding AT at the end of my debug message is totally acceptable.
Thanks a lot!

[Maria Gilje]

Hi Alan-Ni,

Alan-Ni said:

"""When using external MCUs like you are, you connect the indicate pin to the external MCU and use the toggling of the indicate pin to re-enable the UART via the power pin"""

Does that means normally one should send power up signal to 91XX through Power pin to wake up the SiP? Or if the external MCU was also in sleep mode should be able to be wake up through this indicate pin?

Honestly, I don't know. My paraphrasing may have made this unclear. This is the original message:

"The indicate pin is configured to the led0 in nRF9151DK. When you are in sleeping and are receiving data from network or get unsolicited notifications, the indicate led0 is flashing. The idea is that with external MCU, you connect the indicate pin to the external MCU, and use the toggling of the indicate pin as your cue to re-enable the UART (via the power pin)."

If the above quote does not help your understanding I will ask for clarification internally.

Alan-Ni said:

For the debug function, I've read the mentioned part of the code, and saw the code comment saying "We ignore everything before the start of the AT-command.",
It looks like there were some garbage ignoring design already, so I tested again to input some random string and get an ERROR response as expect.
However I checked the comment again and notice it says "before the start of the AT command", so I guess a starting point of AT must exist to avoid getting that ERROR.
I tested again, I append an AT at the end of the random string, and this time I get an OK instead of ERROR.
So... that totally is a problem solved to me, adding AT at the end of my debug message is totally acceptable.
Thanks a lot!

Great!

Best regards,

Maria