Problems with initializing the UART (Error code 0x08)

[AHass]

Hi,

I tried to implement the UART in my code, based on the UART example code. Just as in the example, I first define the struct with the pin numbers:

const app_uart_comm_params_t comm_params =
      {
          RX_PIN_NUMBER,
          TX_PIN_NUMBER,
          RTS_PIN_NUMBER,
          CTS_PIN_NUMBER,
          UART_HWFC,
          false,
#if defined (UART_PRESENT)
          NRF_UART_BAUDRATE_115200
#else
          NRF_UARTE_BAUDRATE_115200
#endif
      };

The pins in this struct are after initialization: 8, 6, 5 and 7 (respectively) just as in the example code. After initializing the rest of my peripherals, I try to initialize the UART (with FIFO):

// Initialize.
    log_init();
    timers_init();
    buttons_leds_init(&erase_bonds);
    power_management_init();
    ble_stack_init();
    adc_configure();
    gap_params_init();
    gatt_init();
    advertising_init();
    db_discovery_init();
    services_init();
    conn_params_init();
    peer_manager_init();
    get_dev_addr();

    /* nach diesem Befehl ist err_code = 0x08 */
    APP_UART_FIFO_INIT(&comm_params,
                       UART_RX_BUF_SIZE,
                       UART_TX_BUF_SIZE,
                       uart_error_handle,
                       APP_IRQ_PRIORITY_LOWEST,
                       err_code);

    APP_ERROR_CHECK(err_code);

But this command returns the error code 0x08. When I debug at the "APP_UART_FIFO_INIT" command and step into the command app_uart_init, the values of comm_params have really fancy values as shown in the picture below.

I assume this might have something to do with the error?

I've already seen some similar issues that other people had. When I turn off the nRF_Log, it still does not work.

Thank you kindly for your help.

[Karl Ylvisaker]

Hello,

But this command returns the error code 0x08. When I debug at the "APP_UART_FIFO_INIT" command and step into the command app_uart_init, the values of comm_params have really fancy values as shown in the picture below.

Could you make sure that DEBUG is defined in your preprocessor defines, like shown in the included image?
 
This will make the error be logged in a readable form, along with which function generated the error.
Please do this, and let me know which function is generating the error, so we may take a look at what might be causing this.

I tried to implement the UART in my code, based on the UART example code. Just as in the example, I first define the struct with the pin numbers:

Is your other code ( which you are adding UART to ) based on one of the SDK examples? If so, which examples is it based on?
It could indeed be an issue if your project is already using UART for your logger module.

Looking forward to resolving this issue together!

Best regards,
Karl

[AHass]

Hi Karl,

thank you for your fast reply.

Karl Ylvisaker said:

Is your other code ( which you are adding UART to ) based on one of the SDK examples? If so, which examples is it based on?

I am afraid my answer to this cannot be very clear. The thing is, that I already merged the example nfc_text_record into the ble_app_proximity example successfully. I also added some of my own code to the main.c file and altered the sdk_config.h file. So my current code is kind of a hybrid between multiple example code projects and my own code. I am using the SDK 17.0.2.

Karl Ylvisaker said:

It could indeed be an issue if your project is already using UART for your logger module.

That's what I read on other similar topics in the forum, so I just blindly tried and removed log_init() from my initialization code by commenting it out. When I do this, there is no failure and my printf("Initialized"); works, at least I am seeing the string in my terminal.

In respect to debugging I am not quite sure if I did correctly what you asked for. I've defined DEBUG in the project options. Then I tried to follow this tutorial video in order to learn how I can make use of the debugging tools in SES and how to use the call stack for tracking where the error comes from. However, there where some issues with this. First thing was that my app_error.h file looks different than in the video. In the video (around 1:25) the app_error_handler is different than mine (I only have app_error_handler_bare which has fewer handover variables). I also cannot set any breakpoints there, they are always marked with a question mark. But my code does not seem to use the app_error.c functions anyway. Instead, it uses app_error_fault_handler from the file app_error_weak.c. When I set a breakpoint in this file as shown in the picture, I get the shown call stack.

Thank you.

[Karl Ylvisaker]

Hello again,

AHass said:

thank you for your fast reply.

No problem at all, I am happy to help!

AHass said:

I am afraid my answer to this cannot be very clear. The thing is, that I already merged the example nfc_text_record into the ble_app_proximity example successfully. I also added some of my own code to the main.c file and altered the sdk_config.h file. So my current code is kind of a hybrid between multiple example code projects and my own code. I am using the SDK 17.0.2.

That is perfectly fine - merging different examples to form the functionality you are after is an all right approach. There is no reason not to re-use code from the SDK examples.
Often, it is the configuration in sdk_config that is hard to nail down properly, when merging different examples.
Would you mind sharing your sdk_config file?

AHass said:

That's what I read on other similar topics in the forum, so I just blindly tried and removed log_init() from my initialization code by commenting it out. When I do this, there is no failure and my printf("Initialized"); works, at least I am seeing the string in my terminal.

If you have disabled the logger, then you will not see the DEBUG output I requested in my previous comment. What you might want to do, however, is to change the logger's backend to instead use RTT logging, instead of UART - if you intend to use the UART for something else in your application. This way, you can see the loggers output in an RTT terminal ( such as RTT Viewer by Segger, or the debug terminal in SES ). I highly recommend making use of the logger module during your development, since it comes with a many beneficial features compared to using retargeted printf statements.
If you intend to change to the RTT backend, you will have to make the following changes in your sdk_config file:

#ifndef NRF_LOG_BACKEND_RTT_ENABLED
#define NRF_LOG_BACKEND_RTT_ENABLED 1
#endif

#ifndef NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED
#define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0
#endif

AHass said:

However, there where some issues with this. First thing was that my app_error.h file looks different than in the video. In the video (around 1:25) the app_error_handler is different than mine (I only have app_error_handler_bare which has fewer handover variables). I also cannot set any breakpoints there, they are always marked with a question mark. But my code does not seem to use the app_error.c functions anyway. Instead, it uses app_error_fault_handler from the file app_error_weak.c. When I set a breakpoint in this file as shown in the picture, I get the shown call stack.

This depends on how you have implemented the application error handler. The default error handler is just to reset the device when an error is passed to it.
Please enable the RTT backend, and try to see if this does not output a more detailed description of the encountered error to your SES debug terminal ( or RTT Viewer ). 

Best regards,
Karl

[AHass]

Hi Karl,

Karl Ylvisaker said:

If you have disabled the logger, then you will not see the DEBUG output I requested in my previous comment

Yes, that was clear to me. It was intended more for finding out where the problem is (especially if it is due to a double initialization of the UART). 

However I've changed my debugging tool to RTT by changing the sdk_config as you described. Now both the RTT logger and the UART work perfectly fine. And the RTT viewer really is a great tool as a debug logger.

Thanks for your help!