MPSL Assert Error and Arch_Except Reason 3 error when using BLE

[mchamberlain1980]

Hello, I have a custom board that was designed for me, but based off of the Acconeer XM126.  It is very similar with a few minor differences.  The person who designed it has bailed and is no longer reachable.  I am a mechanical engineer with limited coding and electrical knowledge.  I have had to stumble my way through.  There were multiple errors with the board that I have had to fix so far including the wrong HF crystal.  He originally had a 24mhz crystal and I had it replaced with a 32 and proper load capacitance.  The other issue is that he added a push button for BLE pairing.  It appears he meant to send 1.8v to pin y23 when the button is pushed.  It is incorrect and is sending 1.8v to y23 all the time.  I don't know if that could be an issue or not.  I'm not sure where the call out would be for what to do with that pin when it was getting the voltage.  I have searched his source and header files.  The board works with the radar sensor when I flash it with normal distance detecting programs.  However, when I load my program or any example program that uses BLE it gives me the errors I have attached.  MPSL Assert 112, 2185 and Arch except reason 3.  Also, zephyr fatal error 3: Kernel oops on cpu 0, fault during interrupt handling.  This is the last piece of the puzzle for me.  Does anyone have any idea what this might be?  Please remember I am limited in my knowledge.  I have already spent thousands to get here, so I am trying to solve this on my own.  Thanks.

[Edvin]

Hello,

mchamberlain1980 said:

Another quick question

Me and Jonathan discussed this a while back, but be aware that we are not familiar with Acconeer. So I can't really help you with that, without knowing what it is. You do however mention mcumgr. If you flash a sample from NCS, it will overwrite any bootloader that you may have pre-programmed on your board. 

So if you want the bootloader back, you need to flash it using jlink. Again, I am not familiar with Acconeer, but I guess it is included in the application that you build there (if it works the same way as in our SDK), but you need to flash it using JLink.

mchamberlain1980 said:

However, when I flash it and open a putty window I just get ***Booting nRF Connect SDK v2.5.0*** followed by Starting Nordic UART service sample

The "Starting Nordic UART service example" is coming from the uart_init() function. Since we want to check the HFXTAL, we need to do this before we start the Bluetooth stack, so try the following:

int main(void)
{
    int blink_status = 0;
    int err = 0;

    configure_gpio();
    
    NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_HFCLKSTART=1;
    while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
    {
        // Do nothing
    }
    LOG_INF("HFCLK started successfully. Stat: 0x%08x", NRF_CLOCK->HFCLKSTAT);
    
    err = uart_init();
    if (err) {
        error();
    }

    if (IS_ENABLED(CONFIG_BT_NUS_SECURITY_ENABLED)) {
        err = bt_conn_auth_cb_register(&conn_auth_callbacks);
        if (err) {
            printk("Failed to register authorization callbacks.\n");
            return 0;
        }

        err = bt_conn_auth_info_cb_register(&conn_auth_info_callbacks);
        if (err) {
            printk("Failed to register authorization info callbacks.\n");
            return 0;
        }
    }

    err = bt_enable(NULL);
    if (err) {
        error();
    }
    LOG_INF("Bluetooth initialized");

If you do this, does it still say "Starting Nordic UART service example"?

Best regards,

Edvin