nrf52832 crash since uart/log disabled

RE: nrf52832 crash since uart/log disabled

opasutto — Tue, 25 Apr 2023 09:28:07 GMT

Hi Einar, thank you for your answer.

Yes all the devices are running the exact firmware, the majority don't have any problem, but for those that have the problem, it is in the majority of the cases an easy to reproduce problem.

At first I was also thinking that it could be a timing related problem. But now I think that it may be an hardware problem since I have removed all the logging in my test firmware and found that for the problematic devices, I only had to initialize UART0 to have the problem, and to comment it to solve it. For the non problematic devices, this modification doesn't have any consequence.

I think it is more related to the UART controller having an influence on some other controllers as the initialisation of the RX and TX pins doesn't change anything, it is really the following lines that makes all the difference:

NRF_UART0->TASKS_STARTTX = 1;
NRF_UART0->TASKS_STARTRX = 1;

Anyway, I think that I will stop investigating for the moment, I just hope that there is not some more hidden problems... Thank you again

RE: nrf52832 crash since uart/log disabled

Einar Thorsrud — Mon, 24 Apr 2023 07:43:17 GMT

Hi,

Are the failing and non-failing devices running the exact same firmware? Meaning the issue only occurs in devices where you had disable logging in the firmware, but also only in a small portion of those devices?

It is difficult to say what goes wrong in your firmware, but logging changes timing of the application, and the Raw UART even more so, as it is blocking. So if you have parts of your application that is sensitive to changes in timing, those issues could surface now. I am unfortunately not able to be more specific, but that is my best hypothesis.

RE: nrf52832 crash since uart/log disabled

opasutto — Fri, 21 Apr 2023 13:48:10 GMT

Hi, we have currently identified about 30 devices with this issue out of several thousands. We are using the S132 2.0.0 (the one furnished with the SDK v11) and unfortunately, we aren't able to update the softdevice part in our product...

On some problematic devices, it's easy to reproduce the issue. For example, one one device, the only operation needed is to connect to it with the nRF connect mobile app, and instantanely, the connection is closed by the device:

Advertising is stopped, SPI is not responding and the only solution is to restart the device.

One another device, after the power on I can observe that the advertising is started but only for 1 or 2 seconds, it is stopped without reasons.

So far for all the problematic devices, the solution to correct the problem is to add at the start of the program a call to the function log_raw_uart_init:

uint32_t log_raw_uart_init()
{
    // Disable UART
    NRF_UART0->ENABLE = UART_ENABLE_ENABLE_Disabled;

    // Configure RX/TX pins
    nrf_gpio_cfg_output( TX_PIN_NUMBER );
    nrf_gpio_cfg_input(RX_PIN_NUMBER, NRF_GPIO_PIN_NOPULL);

    // Set a default baud rate of UART0_CONFIG_BAUDRATE
    NRF_UART0->PSELTXD  = TX_PIN_NUMBER;
    NRF_UART0->BAUDRATE = UART0_CONFIG_BAUDRATE;

    NRF_UART0->PSELRTS  = 0xFFFFFFFF;
    NRF_UART0->PSELCTS  = 0xFFFFFFFF;

    // Disable parity and interrupt
    NRF_UART0->CONFIG   = (UART_CONFIG_PARITY_Excluded  << UART_CONFIG_PARITY_Pos );
    NRF_UART0->CONFIG  |= (UART_CONFIG_HWFC_Disabled    << UART_CONFIG_HWFC_Pos   );

    // Re-enable the UART
    NRF_UART0->ENABLE           = UART_ENABLE_ENABLE_Enabled;
    NRF_UART0->INTENSET         = 0;
    NRF_UART0->TASKS_STARTTX    = 1;
    NRF_UART0->TASKS_STARTRX    = 1;

    return NRF_SUCCESS;
}

And later, if I comment the line NRF_UART0->TASKS_STARTTX = 1; in this function,the problem reappears...

So it seems that there is a workaround to our problem, but we would like to understand what is going on, because maybe there are other problems not yet detected.

Thank you again

RE: nrf52832 crash since uart/log disabled

Einar Thorsrud — Thu, 20 Apr 2023 13:24:54 GMT

Hi,

How many devices do you see this issue on? Have you been able to see a pattern for when it is triggered on the devices where you see it? If so, perhaps it is possible to find a way to reproduce the issue more easily so that it can be debugged.

Which exact S132 2.0.x version are you using?