serial_lte_modem AT#XFTP="put" SLM data mode and escaping data?

So I have to upload a bunch of files, some contain arbitrary data that might contain +,\r,\n,\ ext

So there are two different ways of using the FTP put command, one is in SLM data mode, the other is inline in quotes and I am having huge issues with both

**inline Mode?**
AT#XFTP="open","******username********","*******password*****","*******domain*******"
AT#XFTP="verbose","on"
AT#XFTP="binary"
AT#XFTP="put","test.txt","this is test content"
AT#XFTP="close"


**SLM Data Mode**
AT#XFTP="open","******username********","*******password*****","*******domain*******"
AT#XFTP="verbose","on"
AT#XFTP="binary"
AT#XFTP="put","test.txt"
this is test content
AT#XFTP="close"

We can talk about these two options:

Option1 is what I call inline mode:

if I try to include a  \" inside the first option, or a \r\n in the next the modem will just lock up for a long time. Is there any way to send a bunch of arbitrary binary data as long as I escape it somehow? since backslash doesn't seem to be working

Example that will fail:

AT#XFTP="open","******username********","*******password*****","*******domain*******"
AT#XFTP="verbose","on"
AT#XFTP="binary"
AT#XFTP="put","test.txt","this is\" test content"
AT#XFTP="close"

Option2: Is what you guys call SLM data mode:

According to the documentation and from what I can see in the code, the only way the modem should exit SLM data mode is after a timeout, or by sending +++

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/serial_lte_modem/doc/slm_data_mode.html

But this doesn't happen, it only seems to exit SLM mode when I send a \r\n but there appears to be no way of escaping this?

Another problem is if I just pretend the first issue isnt a thing and remove all new lines from my data(which I really can't do, this is just for exploring the other problem I am having) and send +++ it shows up in the file that is uploaded to the server?

Example that will write part of a file and then get an error because it drops out of SLM too soon:

AT#XFTP="open","******username********","*******password*****","*******domain*******"
AT#XFTP="verbose","on"
AT#XFTP="binary"
AT#XFTP="put","test.txt"
this is \r\ntest content+++
AT#XFTP="close"

If I try to use the +++ as intended from the documentation:

AT#XFTP="open","******username********","*******password*****","*******domain*******"
AT#XFTP="verbose","on"
AT#XFTP="binary"
AT#XFTP="put","test.txt"
this is test content+++
AT#XFTP="close"

I end up with a file on the server including the +++:

this is test content+++

This example will also fail if you do not send a \r\n at the end of the test content line even though the +++ is supposed to terminate it.

Few quite baffling things that do not follow normal conventions or even the documentation?

Parents
  • Hi Kyle,

    Thanks for your feedback, I have tested your observation and agree that we should improve the implementation of these parts.

    I will talk with our development team and give you a reply later.

    Best regards,

    Charlie

  • Charlie,

    Did you hear back from the dev team about this issue?

    Thanks,

    Kyle

  • 1) I have checked the logs you shared on the former post. I can recreated this issue with Link Monitor, but test with other serial terminal(CoolTerm) has no issue. It seems Link Monitor add something else when it meet CR or CR LF. I will report this to our development team and give you reply later.

    2) I have read the ping failure log. It looks ok as a cellular device, the response time is acceptable. Some domains including nordicsemi.com shut down ping response to repent Ping of Death (POD) attach, ping with PC also not work with them. The operator DNS server may also have some special rule to prevent you access some black lists for some specific devices types, you may check with expert on this field or send a email to ask your operator support.

    Best regards,

    Charlie

  • I know it has been a while,

    1. I have similar behavior even when sending it directly from a micro

    2. that explains why nordicsemi.com does not respond, but many other domains like the captus.ca used above also has issues sometime... seemingly 80% of the time? What is weirder is older modems in the field do not have this issue on the same network. I lost the VM I was working in for those modems so I have no information about what MFW file or anything I had loaded into them.

    Edit: I should add this also is happening on multiple different providers.

  • Hi Kyle,

    1) It would be very challenging for us to debug just from the description. Are you able to do a recording of uart with a logic analyzer between the host and your host and nRF9160? also include the log printout from nRF9160DK.

    Have you tested with sending hex content directly(through CoolTerm)? Compared with using LinkMonitor, the difference is quite clear to see when you just send hex content through CoolTerm.

     2) Ok, sounds like related to the MFW versions. Do you still remember which MFW version has fewer issues?  Is it possible to do a ping test with two devices with the latest MFW and old MFW at the same time? It would be great if you can share a log for this kind of experiment.

    Best regards,

    Charlie

  • Hi Charlie,

    1) Yea we are having new boards made that will have the serial pins between the two with accessible test pads

    2) I have some old modems here that have MFW in them that work great, but I do not remember the version due to loss of that VM and notes associated. Is there any way to query the MFW version over serial?

    Thanks,

    Kyle

  • 1) Good, look forward to seeing your sharing.

    2) AT+CGMR can be used to query the MFW version.

    Best regards,

    Charlie

Reply Children
Related