SLM HTTP client hangs with large payload

[Anthony Ambuehl]

I recently switched  from 1.5.1 to 1.6.1 and I'm now finding the SLM is misbehaving.

When I try to send a large payload such as 933 bytes of data, I find the CTS signal goes low after 274 bytes of data were sent.  (There is some buffering in my mcu so probably less received at SLM uart) 

It seems like the SLM data mode uses a ring buffer that is only 256 lines and the datamode cannot handle payloads longer than this.  

Please confirm large payloads work in 1.6.1.  

Also any advice on how to get debug logging from SLM_AT_HOST and SLM_AT_HTTPC ?  I'm running from SES with stock SLM example...

[Anthony Ambuehl]

I'm also seeing this sequence which appears to be caused by a small change in timing from my system due to a new CRITICAL_SECTION i added. 

00> [00:00:57.125,701] <inf> httpc: Setting up TLS credentials
00> [00:00:59.010,589] <inf> httpc: Connected to api.cloud.calahealth.com
00> [00:00:59.039,855] <inf> at_host: Enter datamode
00> [00:00:59.043,090] <inf> at_host: Raw send 1
00> [00:00:59.069,580] <inf> at_host: Raw send 255
00> [00:00:59.095,764] <inf> at_host: Raw send 256
00> [00:00:59.109,893] <inf> at_host: Raw send 136
00> [00:00:59.738,159] <inf> at_host: Exit datamode

The first "Raw send" with only 1 byte seems to really screw things up.. I always get an empty response XHTTPCRSP:0,1

If I change slm_at_host.c line 36 

#define UART_RX_TIMEOUT_MS      1

to be a larger number such as 5, the 1 byte raw_send goes away.

[Håkon Alseth]

Hi,

Anthony Ambuehl said:

I'm also seeing this sequence which appears to be caused by a small change in timing from my system due to a new CRITICAL_SECTION i added. 

00> [00:00:57.125,701] <inf> httpc: Setting up TLS credentials
00> [00:00:59.010,589] <inf> httpc: Connected to api.cloud.calahealth.com
00> [00:00:59.039,855] <inf> at_host: Enter datamode
00> [00:00:59.043,090] <inf> at_host: Raw send 1
00> [00:00:59.069,580] <inf> at_host: Raw send 255
00> [00:00:59.095,764] <inf> at_host: Raw send 256
00> [00:00:59.109,893] <inf> at_host: Raw send 136
00> [00:00:59.738,159] <inf> at_host: Exit datamode

The first "Raw send" with only 1 byte seems to really screw things up.. I always get an empty response XHTTPCRSP:0,1

I am glad to hear that you found the root cause of the issue, and a workaround for this.

Anthony Ambuehl said:

#define UART_RX_TIMEOUT_MS      1

to be a larger number such as 5, the 1 byte raw_send goes away.

I will request that this is changed, and can be configurable by the application as a feature request to the SLM team.

 

Kind regards,

Håkon

[Anthony Ambuehl]

Hello Håkon..

Perhaps the slm_at_httpc.c code should remove the OK after partially sending data.  The other clients (ftp, mqtt, tcp) don't do this, I have no idea why httpc should be different.

[Håkon Alseth]

Hi,

 

Anthony Ambuehl said:

Perhaps the slm_at_httpc.c code should remove the OK after partially sending data.  The other clients (ftp, mqtt, tcp) don't do this, I have no idea why httpc should be different.

I will mention this in the internal jira.

 

But, what I was also made aware is that it is recommended to use ncs v1.7.0 for SLM, mainly due to this bug fix:

https://github.com/nrfconnect/sdk-nrf/commit/87ba51dbed3a4988eece125d8953d38ea78d6ed1

 

Kind regards,

Håkon