This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Identifying different types of UART errors

I read here...

NRF52840_PS_v1.1.pdf
Peripherals > UART (6.33.7)

“An ERROR event, in the form of a framing error, will be generated if a valid stop bit is not detected in a frame. Another ERROR event, in the form of a break condition, will be generated if the RXD line is held active low for longer than the length of a data frame. Effectively, a framing error is always generated before a break condition occurs”

When these ERROR events get passed up to the serial event handler, every error looks like NRF_SERIAL_EVENT_DRV_ERR. I would like to be able to identify the specific kind of UART error that is happening --- i.e., Is a stop bit missing, or has RXD been held low for longer than 1 data frame?

I would also like to know:

  1. Are there other types of framing errors besides missing stop bit? Other types of break conditions besides RXD being held low?
  2. Do both Tx and Rx errors get sent to NRF_SERIAL_EVENT_DRV_ERR? What kind of Tx errors are there? 
  3. Once I intentionally held the RXD line low forever, and I got 2 NRF_SERIAL_EVENT_DRV_ERRthen no more errors, even though the RXD line was still being held low. Is this expected behavior? Other times, I get a flood of NRF_SERIAL_EVENT_DRV_ERRand I don't know what is causing it. 

--------------------

One thing I tried, following the instruction here (https://devzone.nordicsemi.com/f/nordic-q-a/37270/nrf_serial_event_rx_data-never-triggered):

was I set a debug break point and found:
p_event->data.error.error_mask = 0x00000004

But in nrf_uart.h error_mask value 0x04 doesn't seem to exist. What does this error mask correspond to? In general, how can I find out what error is associated with a given error mask?

typedef enum
{
    NRF_UART_ERROR_OVERRUN_MASK = UART_ERRORSRC_OVERRUN_Msk,   /**< Overrun error. */
    NRF_UART_ERROR_PARITY_MASK  = UART_ERRORSRC_PARITY_Msk,    /**< Parity error. */
    NRF_UART_ERROR_FRAMING_MASK = UART_ERRORSRC_FRAMING_Msk,   /**< Framing error. */
    NRF_UART_ERROR_BREAK_MASK   = UART_ERRORSRC_BREAK_Msk,     /**< Break error. */
} nrf_uart_error_mask_t;

--------------------
Generally, I would like to know all the different things that trigger NRF_SERIAL_EVENT_DRV_ERR,
because I am getting a lot of these errors and I would like to figure out the specific source of these errors in order to troubleshoot them.

Parents
  • Hello,

    Generally, I would like to know all the different things that trigger NRF_SERIAL_EVENT_DRV_ERR,
    because I am getting a lot of these errors and I would like to figure out the specific source of these errors in order to troubleshoot them.

    I am sorry to hear that you are facing so many unknown errors.
    Could you confirm for me that you have DEBUG defined in your preprocessor defines, and that all calls to Nordic SDK Functions that returns error codes are passed to an APP_ERROR_CHECK?
    The following image shows how you may check to see that DEBUG is defined:

    If you have DEBUG defined, and make sure to pass the returned error codes to an APP_ERROR_CHECK, then - in the case of an error != NRF_SUCCESS - a the particular error and returning function will be outputted to the log, before the application is reset.
    Please check to see if you have done these things, and if you have, please share the message that is output to the logger. 

    Looking forward to resolving these issues together!

    Best regards,
    Karl

Reply
  • Hello,

    Generally, I would like to know all the different things that trigger NRF_SERIAL_EVENT_DRV_ERR,
    because I am getting a lot of these errors and I would like to figure out the specific source of these errors in order to troubleshoot them.

    I am sorry to hear that you are facing so many unknown errors.
    Could you confirm for me that you have DEBUG defined in your preprocessor defines, and that all calls to Nordic SDK Functions that returns error codes are passed to an APP_ERROR_CHECK?
    The following image shows how you may check to see that DEBUG is defined:

    If you have DEBUG defined, and make sure to pass the returned error codes to an APP_ERROR_CHECK, then - in the case of an error != NRF_SUCCESS - a the particular error and returning function will be outputted to the log, before the application is reset.
    Please check to see if you have done these things, and if you have, please share the message that is output to the logger. 

    Looking forward to resolving these issues together!

    Best regards,
    Karl

Children
  • Hi Karl,

    Thanks so much for your reply. I have these log-related preprocessor defines:

    #define NRF_LOG_DEFERRED 0
    #define NRF_LOG_BACKEND_RTT_ENABLED 1

    #define NRF_LOG_ENABLED 1

    I believe 4 is debug.

    But DEBUG is not here (see screenshot):

    What does that mean that it is missing? Should I type it in directly? I have never added anything to this list directly

    ----------------------------------------------------------------------------------------

    The error I see is just this, over and over again in a constant flood: 

    The code that logs the errors is as follows:

    void serial_event_handler(struct nrf_serial_s const * p_serial, nrf_serial_event_t event)
    {
    	switch (event)
    	{
    	...
    	
    	case NRF_SERIAL_EVENT_DRV_ERR:
    		NRF_LOG_ERROR("NRF_SERIAL_EVENT_DRV_ERROR");
    		break;
    	}
    	
    	...
    }

    Interestingly, the app usually starts out OK with no errors, and at some point later the flood starts happening. I timed it a few times to see how long after pressing "start" on the debugger the error flood started -- on different occasions, it was 55s, 1m12s, 7m27s, 40s -- so you can see it varies.

    I do have APP_ERROR_CHECK everywhere, except not for gpio operations. i.e. I don't do APP_ERROR_CHECK after nrf_gpio_cfg_input() etc.

    EX, here  is some relevant code: 

    Note -- the DEBUG statement in this code snippet never prints out, so it seems like ever time I call nrf_serial_write, I get NRF_SUCCESS. 

    The errors don't impede other app function (e.g. I can still establish a BLE connection just fine), so it isn't a problem in that sense. But I just want to have the capability to investigate what is causing them. 

    For ex: What does error_mask = 0x00000004 mean?  Can you tell me how to find the error codes in the code? 

    Can you also please answer my question 1-3 from the original message?

    Thanks a lot!

  • Hi,

    nordev said:
    Thanks so much for your reply.

    No problem at all, I am happy to help!

    nordev said:
    I have these log-related preprocessor defines:

    Thank for clarifying! For future reference, it would be easier if you share the contents of the sdk_config file, instead of copying / screenshotting select parts.

    nordev said:

    The errors don't impede other app function (e.g. I can still establish a BLE connection just fine), so it isn't a problem in that sense. But I just want to have the capability to investigate what is causing them. 

    For ex: What does error_mask = 0x00000004 mean?  Can you tell me how to find the error codes in the code? 

    nordev said:
    What does that mean that it is missing? Should I type it in directly?

    Yes, you may add it directly there, please do this, and see if you then get a more detailed error message output to your log.

    nordev said:
    Interestingly, the app usually starts out OK with no errors, and at some point later the flood starts happening. I timed it a few times to see how long after pressing "start" on the debugger the error flood started -- on different occasions, it was 55s, 1m12s, 7m27s, 40s -- so you can see it varies.
    nordev said:
    Can you also please answer my question 1-3 from the original message?

    I think there might be some confusion / double-crossing here between the UART driver, and the serial port library..
    Could you verify for me whether you are looking to use the UART driver or library, or the serial port library? Please note that the serial port library is more complex, and requires more to make work, than the UART driver and/or library. The Serial port library is also legacy as of SDK v.17. Which SDK version are you using, by the way?
    Your original ticket text leads me to believe you are looking to use the UART peripheral with the UART driver / library, but all your included code points to the serial port library instead.

    nordev said:
    Note -- the DEBUG statement in this code snippet never prints out

    What is your LOG level set to, are you sure that you are writing out DEBUG logs? 

    nordev said:
    I do have APP_ERROR_CHECK everywhere, except not for gpio operations. i.e. I don't do APP_ERROR_CHECK after nrf_gpio_cfg_input() etc.

    Great! No need for APP_ERROR_CHECKS for functions that do not return anything, that is fine.

    Best regards,
    Karl

Related