Hard fault after uart printf

[Mouss]

Hello , 

On NRF52840 DK my logger works fine and I get no problem with printf(). However, on my custom board the program goes into hard fault with the following : 

0x4001

0x2003 FF14

Matter of fact, for my init function 

void uart_init(void){
    uint32_t err_code;

    bsp_board_init(BSP_INIT_LEDS);

    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
      };

    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);
}

And I added retarget.c for my project. The pins are defined in pca10056.h

Like I said everything works just fine on NRF52840 DK, and I cannot remove the printf example because i'm including a library which needs printf. 

Any idea about the probleme ? 

[Jørgen Holmefjord]

Hi,

Do the hardfault happen after a call to printf, or once it runs on the custom board?

Have you enabled the retarget functions in your sdk_config.h file?

// <q> RETARGET_ENABLED  - retarget - Retargeting stdio functions
 

#ifndef RETARGET_ENABLED
#define RETARGET_ENABLED 1
#endif

Which pins are you using for the UART peripheral? Are these pins connected/pulled to a given state on the custom board? If not, you may get an error on the RX line, putting your application in the error handler.

Best regards,
Jørgen

[Mouss]

Hi, 

The hardfault happen right after a call to printf but only on the custom board (not on nrf52840 DK) .

Yes indeed, I have enabled the retarget functions on my sdk_config.h and like I said everything works fine on nrf52840 DK.

When I was testing my code on the DK I used the VCOM pins. 

#define RX_PIN_NUMBER  8
#define TX_PIN_NUMBER  6
#define CTS_PIN_NUMBER 7
#define RTS_PIN_NUMBER 5
#define HWFC           true

Can you tell me what do you mean by "pins connected/pulled to a given state on the custom board"

On my custom board, these pins are exposed to an external connector .

I also switched to other pin ( RX P0.3 and TX P0.4 which are also exposed for testing purposes) .

Could you explain to me why do I need my pins pulled / connected to a specific state in order to avoid hardfault ? 

Kind regards , 

Moussaab 

[Jørgen Holmefjord]

As you can read from the UARTE peripheral documentation about Error conditions:

"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."

These errors will not generate hardfault, but the app_uart library will report an event, APP_UART_COMMUNICATION_ERROR, which by default is passed to the APP_ERROR_CHECK() in the event handler. This check will put the application in the error handler if the error code is not zero (NRF_SUCCESS):

void uart_error_handle(app_uart_evt_t * p_event)
{
    if (p_event->evt_type == APP_UART_COMMUNICATION_ERROR)
    {
        APP_ERROR_HANDLER(p_event->data.error_communication);
    }
    else if (p_event->evt_type == APP_UART_FIFO_ERROR)
    {
        APP_ERROR_HANDLER(p_event->data.error_code);
    }
}

Try pulling the RX pin to VDD, or remove the APP_ERROR_CHECK in the UART event handler in your application.

[Mouss]

Hello Jorgen, 

Thank you for your help ! This has solved my problem