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

Initialising peripheral fails NRFX_DRV_STATE_UNINITIALIZED and program hangs with Invalid State hardfault

Hello, I am stuck initalising both TWIM and UARTE. I am focusing on the TWI Scanner example but using TWIM instead of TWI. No matter what I do I cannot get past the initalisation. The problem is that for both peripherals they fail the condition p_cb->state != NRFX_DRV_STATE_UNINITIALIZED.

I am seeing consistantly p_cb->state = 0x28 for UARTE and 0x10 for TWIM.

To simplify the reproduction I've now removed TWIM from my code and am only focusing on UARTE. I am really stuck at the moment and could use some advice.

My setup

  • Development Software:
    • nRF52 SDK v17.0.2
    • No software device
    • IDE: Visual Studio Code v1.53.2
  • Hardware: nRF52 DK (nRF52832) It says 2.0.0 on the sticker, I'm guessing that's the version?
  • Computer Platform: Ubuntu 20.10

Code

extern "C" {
    #include <stdio.h>
    #include "boards.h"
    #include "app_util_platform.h"
    #include "app_error.h"
    #include "sdk_config.h"
    #include "nrf.h"
    #include "nrf_log.h"
    #include "nrf_log_ctrl.h"
    #include "nrf_log_default_backends.h"
}

int main() {
    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
    NRF_LOG_DEFAULT_BACKENDS_INIT(); // Hangs here

    while (true)
    {
        NRF_LOG_INFO("TWI scanner started.");
        NRF_LOG_FLUSH();
    }

    return 0;
}

Preprocessor definitions

  • BOARD_PCA10040
  • NRF52832_XXAA
  • ENABLE_SWO
  • ENABLE_TRACE
  • DEBUG
  • DEBUG_NRF

Screenshots

You can see on the left that state is assigned 0x28. Where does that value come from? Perhaps the variable is uninitalised and random?

SDK Source files

  • /components/libraries/util/app_util_platform.c
  • /components/libraries/util/app_error.c
  • /components/libraries/util/app_error_handler_gcc.c
  • /components/serialization/connectivity/ser_conn_error_handling.c
  • /components/libraries/ringbuf/nrf_ringbuf.c
  • /components/libraries/memobj/nrf_memobj.c
  • /components/libraries/balloc/nrf_balloc.c
  • /components/libraries/atomic/nrf_atomic.c
  • /components/libraries/log/src/nrf_log_frontend.c
  • /components/libraries/log/src/nrf_log_default_backends.c
  • /components/libraries/log/src/nrf_log_backend_uart.c
  • /components/libraries/log/src/nrf_log_backend_serial.c
  • /components/libraries/log/src/nrf_log_str_formatter.c
  • /external/fprintf/nrf_fprintf.c
  • /external/fprintf/nrf_fprintf_format.c
  • /modules/nrfx/drivers/src/nrfx_uart.c
  • /modules/nrfx/drivers/src/nrfx_uarte.c
  • /modules/nrfx/drivers/src/prs/nrfx_prs.c
  • /integration/nrfx/legacy/nrf_drv_uart.c
  • Hi just to report in case this helps anyone else... There seems to be a bug either with the linker itself or maybe binutils (I'm not sure).

    But the problem arises when you copy the text inside nrf_common.ld and paste it into another linker script and use one merged linker script instead of one which includes nrf_common.ld. See issue here: https://devzone.nordicsemi.com/f/nordic-q-a/59161/merging-two-linkerscripts-from-an-nrf5-project-causes-a-malfunction

    I looked at the linker map produced by the two cases.

    1. copying the exact contents of nrf_common.ld and replacing the include "nrf_common.ld"

    2. No copying, and using two linker scripts, where one of them calls include "nrf_common.ld".

    The two cases produce a different linker map and the program won't work. Also when I call arm-none-eabi-objdump I see the the faulty program has wrong VMA addresses for .bss and .data sections compared to the program that works. That is the faulty code has same VMA address as LMA, but I'm not sure if it's enough to cause a hardfault, it's just one difference I noticed.

    My expectation was the two cases would produce the exact same linker map file, but it appears that's not the case.

    Edit: this does not seem to happen with the blinky example

Related