FDS error base num

RE: FDS error base num

tesc — Thu, 08 Nov 2018 12:48:05 GMT

Hi,

I am happy to report that FDS errors will get a separate NRF_ERROR_FDS_ERR_BASE of 0x8600 in sdk_errors.h, for next release of the SDK.

From then on, "FDS_ERR_OPERATION_TIMEOUT = NRF_ERROR_FDS_ERR_BASE" in the definition of FDS return values in fds.h, and there is no longer any overlapping error codes.

Thank you to everyone who have reported this. Your reports are crucial for identifying and fixing issues like this one.

Regards,
Terje

RE: FDS error base num

dare — Wed, 07 Nov 2018 19:36:03 GMT

I too have run into this problem. Although in my case I was trying to develop a consistent way to return errors in a library that wraps FDS.

The lack of consistent error representation in the nRF SDK is a significant liability, IMO, and promotes bugs that could have significant consequences in mission critical applications where checking and handling errors is extremely important.

In the case of the FDS API this is particularly pernicious because no where in the documentation does it warn developers that FDS_ERR_* values are ambiguous with other errors. This is true despite the fact that the FDS APIs use ret_code_t, suggesting a uniform error space. This just seems to be inviting confusion.

I definitely think that Nordic needs to prioritize making their APIs more robust and consistent.

RE: FDS error base num

tesc — Mon, 24 Sep 2018 09:27:06 GMT

Hi,

It is rather a workaround within Peer Manager, where now the Peer Manager event structures (pm_evt_t), some of which return error events of type pm_failure_evt_t, those events now have a bool fds_error which tells you if the address space of the contained error is in FDS_*.

The overall error address space issue is not solved, so this will only tell you how to interpret error codes relayed through the Peer Manager event system. You still need to know how to interpret those error codes differently, depending on whether it is an FDS_ or an NRF_ error.

I will push some more on moving the FDS_ errors to their own number range.

Regards,
Terje

RE: FDS error base num

gnf — Fri, 21 Sep 2018 14:57:14 GMT

Three months later I fell into this trap again... I tried implementing the FDS_ERROR_CHECK custom macro but apparently I did something wrong so that didn't work. Will have to fix that.

Anyway, I saw an interesting note in the release notes of SDK 15.2 (that I just upgraded to), about Peer Manager:

"Error event parameters now specify whether the error code is to be interpreted as an FDS_ error or an NRF_ error."

Is this the same issue, solved somehow inside Peer Manager, or what does it mean? I am just curious to see if Peer Manager has solved it in some other way.

RE: FDS error base num

gnf — Thu, 14 Jun 2018 15:27:08 GMT

Ok, thanks for the fast response. I guess I will go for the FDS_ERROR_CHECK custom macro for the FDS API calls to see how that would work in my code.

Yes, you are right that I am trying to print as much information about the error as possible. I am using the nrf_strerror_get() function for printing out the name of some common errors. That's really useful when debugging.

RE: FDS error base num

tesc — Thu, 14 Jun 2018 14:57:19 GMT

Hi,

Thank you for reporting this and for the suggestion. I will forward the suggestion to the SDK team, maybe they will come up with a solution for a later SDK release, where error codes are not overlapping.

Do I understand correctly that you want to print the textual representation of the error code in your error handler? I.e. programmatically decide which error to report? I can think of two ways to do that (although there are probably more):

First option, use two separate error check macros (APP_ERROR_CHECK for other SDK API calls, and a custom one for instance named FDS_ERROR_CHECK for FDS API calls,)

Second option, change the definition of the enum in fds.h so that FDS_SUCCESS is still 0 but FDS_ERR_OPERATION_TIMEOUT which is the next FDS error code starts at an offset.

The above options have pros and cons, so it all depends on what tradeoff you are willing to do. Separate macros for checking the error opens the door for inadvertently using the wrong macro thus getting an erroneous error message. Changing the library means you must do the same change if porting to a later SDK release, and also always make sure to link only to versions of the FDS library where this change is in place.

Perhaps others have other suggestions, or suggestions for how to mitigate drawbacks of the options outlined above?

Regards,
Terje