I am starting to use FDS for saving data to flash memory. In the "flash_fds" example the macro APP_ERROR_CHECK() is used to check for errors in most of the function calls, for example
rc = fds_stat(&stat);
ret_code_t err_code = app_timer_init();
I now tried using the same type of error handling in my code but recently I ran into an error "0x00000007" which I interpreted as "NRF_ERROR_INVALID_PARAM". But after some investigation I found that I was really seeing the "FDS_ERR_NO_SPACE_IN_FLASH" error.
In fds.h the errors in the "FDS return values." enum overlaps the same error series as the definitions in "nrf_error.h".
I would rather like to see the FDS using some kind of base number, as used in "nrfx_error.h" where NRFX_ERROR_BASE_NUM is defined as 0x0BAD0000 and the rest of the errors are added to this base number.
How would you suggest I solve this in my case?
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?
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.
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.
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.
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.