Errors when running coap_client sample from 2.9.0 SDK

[Sage_Duggal]

Hello all,

I have slightly modified the coap_client sample from the SDK such that the main function is being called on certain actions from another program. I'm getting some very odd behavior. Occasionally, I will get one of the following errors:

This one:

[00:01:06.340,362] <inf> coap_client_sample: The CoAP client sample started. Sending a message before turning modem off.
[00:01:06.340,393] <inf> coap_client_sample: Bringing network interface up and connecting to the network
[00:01:07.374,816] <inf> coap_client_sample: IPv4 Address found 10.60.2.219
[00:01:07.375,366] <inf> coap_client_sample: Initializing CoAP client
[00:01:07.375,396] <err> coap_client_sample: Failed to initialize CoAP client: -28
[00:01:07.375,396] <err> coap_client_sample: periodic_coap_request_loop, error: -28
�*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***rror! Rebooting the device.
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

or this one:

[00:00:41.803,497] <inf> coap_client_sample: The CoAP client sample started. Sending a message before turning modem off.
[00:00:41.803,527] <inf> coap_client_sample: Bringing network interface up and connecting to the network
[00:00:42.328,430] <inf> coap_client_sample: IPv4 Address found 10.60.2.219
[00:00:42.328,948] <inf> coap_client_sample: Initializing CoAP client
[00:00:42.330,688] <inf> coap_client_sample: CoAP POST request sent sent to coap.os.1nce.com
[00:00:42.630,584] <inf> coap_client_sample: CoAP response code: 0x44
[00:00:43.133,056] <err> os: ***** BUS FAULT *****

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

Any idea how to resolve this? I've tried increasing CONFIG_MAIN_STACK_SIZE to 16384, but that hasn't helped.

[Achim Kraus]

Sage_Duggal said:

Occasionally, I will get one of the following errors:

The first, "-28" (-ENOSPC) is caused by calling "coap_client_init()" more than CONFIG_COAP_CLIENT_MAX_INSTANCES. I fail to see, how that happens with "nrf/samples/net/coap_client/src/main.c". There it's called only once in "periodic_coap_request_loop()", which also called only once in "main()".

Did you modify the sample?

The second:

[00:00:42.630,584] <inf> coap_client_sample: CoAP response code: 0x44
[00:00:43.133,056] <err> os: ***** BUS FAULT *****

That's caused by

LOG_INF("CoAP response: code: 0x%x, payload: %s", code, payload);

The sample assumes, that the payload is a 0 terminated string. But that's not granted by CoAP (RFC7252) itself. That C-style 0 termination is not specified, even not for the requested PLAIN_TEXT content format. 

I assume, the sample here works with the default "coap://californium.eclipseprojects.io/obs", because the receive/response buffer is somewhere initialized with 0 and the response is pretty short (time as text "09:52:30", but no terminating 0).

Just as fast work-around, replace the LOG_INF by:

LOG_INF("CoAP response: code: 0x%x, payload: %u bytes", code, len);

and try to check, why "coap_client_init()" may be called more than once.

[Sage_Duggal]

Hi Achim,

Thanks for your response! Yes, I did modify the sample such that coap_client_init() is called more than once. I will figure out how to resolve this problem. Looking at the sample, I'm going to try and break out coap_client_req() into it's own function, or something like that.

I will also try out your LOG_INF idea.

[Sage_Duggal]

Hello Achim,

I modified my code in such a way that prevents coap_client_init() from being called more than once. Thank you for your suggestion.

Now that my code runs many times, I have noticed that the CoAP response code sometimes does not flush via LOG_INF. Is there a specific way to ensure you always wait to receive a callback?

[Achim Kraus]

Sage_Duggal said:

Now that my code runs many times

Great.

Sage_Duggal said:

Is there a specific way to ensure you always wait to receive a callback?

I don't use the client logic of zephyr, I use zephyr coap only for encoding and decoding the messages. So sorry, I don't know the best way to do so. What I see is, the receiving is handled by an other thread, so in my opinion it requires a semaphore (see K_SEM_DEFINE).