nRFCloud CoAP connection timeout

RE: nRFCloud CoAP connection timeout

Carl Richard — Wed, 25 Feb 2026 13:10:02 GMT

Hi again Vincent!

You are welcome.

I don't know of any straight forward way to determine the maximum timeout duration of nrf_cloud_coap_connect(), but It should be tied to the configs I mentioned in my previous message. If you are able to test the device in an environment where the nrf_cloud_coap_connect()-function hangs, it should be possible to experiment a bit and see what determines the timeout.

I will see if I can manage to run some tests here as well.

Best regards,
Carl Richard

RE: nRFCloud CoAP connection timeout

Vincent44 — Tue, 24 Feb 2026 16:15:10 GMT

Thanks for the quick and detailled response.

These are more or less the options I also had in mind.

Is there a way to determine the maximum timeout duration of nrf_cloud_coap_connect() ?

So far, I implemented a timer that periodically feeds the watchdog during the connection process. But nothing prevent that to hang forever ...

RE: nRFCloud CoAP connection timeout

Carl Richard — Fri, 20 Feb 2026 14:22:20 GMT

Hi Vincent!

Thanks for reaching out.

First of all: I think you should try to refactor your code so that that the Watchdog isn't starved when the device cannot connect. As you have observed connection issues isn't necessarily caused by problems that requires a reboot, so when such problems occurs it's better to handle them through other timeout mechanisms. Which leads me to answering your actual question: from what I know the nrf_cloud_coap_connect()function cannot be aborted through the API, but it should eventually timeout if a connection cannot be established. This can take quite some time because of the retry mechanisms as you say, but these should be possible to configure. You can read about some of the different options here. Initially you could for example try to lower CONFIG_COAP_MAX_RETRANSMIT? Its default value is 4.

Alternatively you could try to run nrf_cloud_coap_connect in it's own thread and abort this after a timeout configured by you. This will probably require some cleanup afterwards by closing sockets and such.

Finally, to avoid trying to connect if the coverage is bad it's considered good practice to use the %CONEVAL AT-command to get an evaluation of the LTE-connection that can be used to decide whether it's worth attempting a transmission or not. You could use this before calling nrf_cloud_coap_connect.

I hope some of this helps!

Best regards,
Carl Richard