FDS error base num

[gnf]

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);
    APP_ERROR_CHECK(rc);

 

and

    ret_code_t err_code = app_timer_init();
    APP_ERROR_CHECK(err_code);

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?

[tesc]

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

[gnf]

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.