• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 97 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MCU-PLUS-SDK-AM243X: How did the SDK designers intend for users of the SDK to identify which problem caused an error?

Traveler Hauptman
Prodigy 240 points
Part Number: MCU-PLUS-SDK-AM243X

Throughout the SDK there are functions that assign the same error value to multiple different error conditions. An random example is this code from the octal spi driver

static int32_t Flash_norOspiWrite(Flash_Config *config, uint32_t offset, uint8_t *buf, uint32_t len)
{
int32_t status = SystemP_SUCCESS;
Flash_NorOspiObject *obj = (Flash_NorOspiObject *)(config->object);
Flash_DevConfig *devCfg = config->devConfig;
Flash_Attrs *attrs = config->attrs;

/* Validate address input */
if((offset + len) > (attrs->flashSize))
{
status = SystemP_FAILURE;
}
/* Check if the offset is aligned to page */
if(0 != (offset % attrs->pageSize))
{
status = SystemP_FAILURE;
}

The same error value is assigned to two different error conditions. This seems to be repeated throughout the code base.

This would be considered very poor code in my organization as the only way to debug the code is to instrument the API code with breakpoints every time an error is encountered. Downstream code is unable to do anything intelligent with the error and if the error condition needs to be caught and handled, the validation check code has to be rewritten in dowstream functions.

What is the recommend way to catch and debug errors in user code? Maybe there's a technique I'm unaware of?

  • 0
    TI__Mastermind 28033 points

    Hi Traveler,

    Thanks for your question, I have noted your concern.

    So currently ‘status’ has few different macros which are predefined and is used throughout the SDK code. 
    Few of them include SystemP_SUCCESS and SystemP_FAILURE.

    I can understand your point that a simple statement like Failure is define at various points throughout the code. But in most of the cases this is how you could debug properly. Assume there is an API which enables Phy and returns success if Phy is enabled else failure if Phy is not enabled. Well in this case if the Phy enabling is failed then there will be certain logs printed on the console stating “Phy enabling failed!! Continuing without Phy!!”.

    This should give the developer a specific API to watch out for since it is stating the appropriate failure log message. 
    Apart from this CCS offers a neat way to debug through your code with watchpoints, breakpoints, memory browser and a whole lot of features to help on the debug steps.
    Additionally I am going to check what would be the best practise to debug efficiently and get back to you in few business days.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Kumar
    Prodigy 240 points

    Hi Vaibhav,

    After considering your response, I'm not sure your debugging practices would be anything new or useful.

    Please pass the following on to the SDK architects or team manager:

    Using a unique error number (you have 2 million available!) for each code path allows SDK users to quickly identify the exact nature of the error and eliminate potential causes like wrong configuration, or misunderstanding how the API is designed. Debug log prints are not always sufficient or available.

    Please consider using error numbers that are unique for each error in each SDK call chain. SystemP_FAILURE is fine for a function with a single error cause. However, if that function is propagating errors from subfunction calls, or has multiple failure sources, then error numbers that are unique within that call chain should be used.

    I mention this because of the large number of hours I have spent either replicating preconditions in my own code to figure out what an error cause is, or setting up breakpoints and traces to figure out what the error was. If you could have saved me, a single user, this time by simply using good error number practice, then think of the number of hours across all customers that could be saved!

  • 0 in reply to Traveler Hauptman
    TI__Mastermind 28033 points

    Hi Traveler,

    I have noted your concern. I will share this E2E with the relevant folks to take your inputs into consideration.

    Meanwhile I share this information to the relevant folks, I would like you to go through https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html

    Thanks for your patience.

    Regards,

    Vaibhav