This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Serial LTE Modem SENDTO of hex string bigger than 32 bytes resets the module

Hi,

I have been working with the Thingy:91 at the version 1.2.99 but this also happens on previous versions (I do not know which it was but the serial_lte_modem code had a at#xdatatype command that is no longer existing on version 1.2.0 or 1.2.99) of the SDK. In this version I am using the following functions to try to request a timestamp from an NTP server.

at#xsocket=1,2,0



#XSOCKET: 1, 2, 0, 17


OK



at#xbind=1024



OK


at#xsendto="178.32.88.247",123,0,"1b0000000000000000000000000000000000000000000000e2495ab3c7ae147800000000000000000000000000000000"



Ready

The "Ready" at the end means that the device has rebooted, I assume this is due to an error. This happens when the datatype is 0, which means hexadecimal string and the payload is more than 32 bytes,
which in a hex string would mean 64 bytes.

After doing a little bit of debugging I found out that the error may be in the handle_at_sendto(...) function of the slm_at_tcpip.c file, because I wrote a debugger to see what was inside the "data" vector
just before the line where it may be doing a segmentation error (line 1125). Inside my data vector I saw that there was my complete payload but there were additional strange characters such as '$' and 'É'.

Is there any other way to achieve this kind of communication (sending a hex string of this size) using the serial_lte_modem?

By the way, to communicate with the modem I have been using the LTE Link Monitor.

Thanks, Aleix.

Parents
  • Hi Aleix, 

    Krawlow said:
    In that case I am currently at 1.2.99, specifically, the last time I synced with the master branch was Wednesday 22/04/2020

     Sorry, I'm a little confused. Where do you get 1.2.99 from? We do not use this for NCS, only the Zephyr repo. NCS tag v1.2.0 is likely more correct. Could you please provide a screenshot?

    Anyway, I will forward your request to our R&D engineers. I am not able to set AT#XBIND=1024 as I get ERROR.

    Kind regards,

    Øyvind

  • Hello Øyvind,

    I am sorry to confuse you. When I say that I am on version 1.2.99 I am refering to the following image. For instance, I just was up-to-date with the master branch of the SDK.

    Does that clear out things? By the way, I do not know why would you get an error from AT#XBIND=1024, but maybe you could try without using it, or using another port, I do not use that command with any real intention.

    Thanks,

    Aleix.

  • My apologies, you are correct, that is the documentation for the latest/master repo.

    The R&D engineer has already started work and has reproduced the issue. There is a hard fault when calling k_malloc().  Have a look at this Git PR.

    Can you try to add the following in your prj.conf:

    CONFIG_SLM_UDP_PROXY=y

    Kind regards,
    Øyvind

  • The fix should be in master now. Please update the master repo ( git pull) and run west update. Then add the Config as instructed in my last comment. 

    -Øyvind

  • Hi Øyvind,

    Adding CONFIG_SLM_UDP_PROXY=y in my prj.conf did not solve the problem, however, updating the repo did. Slight smile

    However, I think that the fix caused another different problem, where submitting an AT#RECVFROM command makes my Thingy:91 unresponsive to that and any other commands. The following image shows my execution: in this example I am using a command that I was able to execute successfully last week, which is a simple DNS look-up agaisnt Google servers.

    Maybe I should do some other checks, but in the meantime you get my feedback too.

    Thanks!

    Aleix.

  • Hi!

    Quick update, tried again. Waited a little bit longer before looking up for received bytes and it worked. I apologize for being so impacient yesterday!

    By the way, it is a little bit annoying that when I misspell a command I lose my ability to send commands to the module, similar to what happened there when I asked for the received bytes before they were actually there. Is there anything I can do besides trying to be pacient and be careful with my writing? haha

    Anyway, thanks for your help!

    Aleix

Reply
  • Hi!

    Quick update, tried again. Waited a little bit longer before looking up for received bytes and it worked. I apologize for being so impacient yesterday!

    By the way, it is a little bit annoying that when I misspell a command I lose my ability to send commands to the module, similar to what happened there when I asked for the received bytes before they were actually there. Is there anything I can do besides trying to be pacient and be careful with my writing? haha

    Anyway, thanks for your help!

    Aleix

Children
No Data
Related