BSD error codes

[vkbakken]

extern void bsd_recoverable_error_handler(uint32_t error)

AND

extern void bsd_irrecoverable_error_handler(uint32_t error);

Will return various error codes - is there a list to decipher what they mean? Especially error code 3 seems frequent...

[Håkon Alseth]

Hi,

 

Will return various error codes - is there a list to decipher what they mean? Especially error code 3 seems frequent...

The error codes coming from bsdlib is unfortunately not documented yet, as we are expecting these to change in the future, but this is on the "todo" list internally, along with more documentation in general for bsdlib. What is more important is to see which handler is called. recoverable error is for instance if your link is lost or connection is disrupted in any way, while the irrecoverable one will require a reset.

If you see this error frequently, I suspect it is due to this errata:

https://infocenter.nordicsemi.com/topic/errata_nRF9160_EngA/ERR/nRF9160/EngineeringA/latest/anomaly_160_17.html?cp=2_0_1_0_1_10

Could you try to implement this workaround and see if it has any effect on your debugging experience?

 

Kind regards,

Håkon

[vkbakken]

Haakon,

Thanks for your reply. The fix for the referenced errata is applied. Still there are occurrences of the error (Especially 3).

1. I find that usually it is the recoverable error that is thrown. However - I find it that the link is not really recoverable. Meaning socket operations to the modem will never return. Alas - I do not know error code 3 - so hard to tell what is actually going on.

2. Is there any steps required when recovering from recoverable error handler through any of the API calls in bsdlib?

[Håkon Alseth]

vkbakken said:

1. I find that usually it is the recoverable error that is thrown. However - I find it that the link is not really recoverable. Meaning socket operations to the modem will never return. Alas - I do not know error code 3 - so hard to tell what is actually going on.

In this case, you should be able to close the socket, then reopen a new one without the application going into a bad state. What example are you running, and how are you handling the socket? 

vkbakken said:

2. Is there any steps required when recovering from recoverable error handler through any of the API calls in bsdlib?

That would depend on where you are in your process. Close the socket, and try to open it. If you still get an error, could you check the signal strength using at_client (AT+CESQ)?

 

Kind regards,

Håkon

[vkbakken]

Alrighty,

I was kind of hoping to eak out what error 3 was...

Now - sockets are always closed after use - so they are not held open as this is pretty poor practice. In my case UDP data is sent, an ACK received and socket closed. So I would say that suggested fix is not working. This is product specific code - but generally based on the asset_tracker.

Given the CSQ response - what do you suggest should be done based on strength?

[Håkon Alseth]

3 == generic internal error. a catch all error.

In the last field of the CESQ command, you get the RSRP, which is provided in a integer, where the received signal is calculated: -140 + <num> = <my_current_signal_strength>

If you are around the receiver sensitivity (~-103 to -108 dBm, depending on band etc), you might see issues.

In general, I would recommend you to check if your current modem fw is up to date, as this can have a great impact on the overall stability. You can download the latest modemfw here:

https://www.nordicsemi.com/Products/Low-power-cellular-IoT/nRF9160/Download#infotabs

 

Kind regards,

Håkon

[vkbakken]

Haakon

Not sure if I am able to follow your suggestion. What I see is that when I try to recover from error 3 - then the SDK seems locked in an endless loop calling this function:

int32_t bsd_os_timedwait(uint32_t context, uint32_t timeout)

So there is no way I can simply close a socket and continue....

[Håkon Alseth]

bsd_os_timedwait() was implemented approx. 1 month ago:

https://github.com/NordicPlayground/fw-nrfconnect-nrf/blob/master/lib/bsdlib/bsd_os.c#L172

 

Prior to this, all wait's (including blocking calls) on socket operations were not working properly.

Depending on the tag you're using, this call might not be running as it should. If you have the latest implementation in place, there could also be a corner case that hasn't been handled.

 

Kind regards,

Håkon