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.

[JONATHAN LL]

Hi there Mike, 

Can you share some more info here, its a bit difficult to get in to all the aspects whitout having an overview of the schematic. 

But if the designers bailed and things have not been updated properly, but you have had to fix the physical board then things can be a bit difficult to debug. 

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. 

So looks like most of the HW is ok, but it would be good to see if only a basic sample with BLE would work. 

Have you tested a simple application like Peripheral UART, https://github.com/nrfconnect/sdk-nrf/tree/main/samples/bluetooth/peripheral_uart.


Also feel free to ask about anything and also know that we will help with review schematic and Hardware layout files.

Regards,
Jonathan

[mchamberlain1980]

Hi Jonathan, thank you for the reply.  I will attach the schematic for you to review.  I also have the PCB files, if that matters.  In terms of trying samples, I have tried some from the Acconeer sdk and as long as it does not involve BLE they run fine.  Even the bring up example, which is basically a bunch of tests with the exception of BLE.  However, when I run any sample that tries to use a beacon/BLE I get the same error as with my program.  FYI, my program works on the XM126.  I have tried to go through the schematic the best I can and I don't see a lot of differences to the XM126 other than a charging circuit, push button, and some LED's. 

However, he had put a resistor on the vset circuit of the vol reg and left it out.  It was supposed to go to ground for 1.8v.  So, I put a jumper there and it fixed that problem.  The HF crystal has been replaced, but maybe some solder crossed pads? Or it's a bad crystal?  I did notice the circuit is opposite direction, but from what I read that doesn't matter with the crystal.  Other than that HW wise, there is just that button.  You'll see it on the schematic.  I hope this helps. Also, I will try that periph uart example. 

MikePCB_XM126_v1.0A.PDF

[mchamberlain1980]

Thanks.  I am curious at what the error codes mean.  I am still a little confused about why my program works with the original xm126 board, but not this board if it is a SW or config issue. 

I did notice that I can't flash my program to the xm126 using the 52840dk, only using mcuboot.  I get an error.  However, I can flash it both ways on my board.  I thought that I read if it is setup for mcuboot then it could have some memory issues if flashed by jlink?

My program does use the acconeer sdk.  Does the sdk or config settings matter in terms of the board though?  The xm126 uses the 52840 and the same sensor, of course.  The only major thing that was changed was the bluetooth antenna.  Just a different manufacturer.  

Thanks,

Mike

[JONATHAN LL]

Its clock related,

The MPSL assertion suggests that the 32M crystal did not ramp up, which could indicate a soldering or placement issue with the crystal. Please try to check if the crystal oscillator is able to start by using the code snippet I posted here:  RE: MPSL ASSERT: 112, 2134 if using multiple BLE communication 

So how is it working with another application? If you get one of our BLE apps to run on your device then you have some issues in SW, like manipulating the HFCLK from the application in some way.


Regards,
Jonathan

[mchamberlain1980]

Ok, that makes sense.  I'll try that code for checking ramp up time on the clock.  I haven't tried the other application yet.  I will try that tomorrow.  Is there any chance the load capacitance/crystal capacitors are causing it?  I know they are barely off, but just want to make sure.  

Also, how do I know what capacitors to use on the BLE circuit for matching?

Mike

[mchamberlain1980]

Also, I tried the peripheral_uart example and in my terminal I just get : *** Booting nRF Connect SDK 2.5.0 *** Starting Nordic UART service example.  It just keeps repeating that.  I tried adding in the snippet of code for the clock ramp up time from the thread you posted and I just got errors and couldn't build it.  Not sure what I did wrong there.  I just tried to add it to the uart example.  Would I get the error with the uart or would it just reboot over and over?  Any suggestions with testing the clock?  Sorry, I may be missing something. 

Mike

[JONATHAN LL]

Can you add this before "Bluetooth Initialized". 

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

mchamberlain1980 said:

Sorry, I may be missing something. 

no problem, will try to solve this. 

Regards,
Jonathan

[mchamberlain1980]

I've tried that code, but still get errors with all of it when I compile.  I'm using the peripheral_uart example from the 2.5.0 version sdk.  All I'm doing to copying and pasting it in the main.c file after the defines.  Is there anything else I would need to change or add?  Thanks.

Mike

[mchamberlain1980]

Jonathan,

I did replace the 32mhz crystal on two boards and I am still getting the same error.  Not sure where to go from here.  I wish I could get the code to work for testing the HF clock.  

Mike

[Edvin]

Hello Mike,

Jonathan asked if I could pitch in on this one. As I understand we're trying to figure out whether the 32MHz XTAL is working correctly. 

mchamberlain1980 said:

I've tried that code, but still get errors with all of it when I compile.  I'm using the peripheral_uart example from the 2.5.0 version sdk.  All I'm doing to copying and pasting it in the main.c file after the defines.  Is there anything else I would need to change or add?

Can you please share the file where you tried to enter the code that Jonathan proposed (including the parts that you added)?

Also, please copy and paste the entire build log, including the build errors that you are seeing.

Best regards,

Edvin

[mchamberlain1980]

Hi Edvin,

I did finally get it to compile after adding it to the section below of peripheral_uart in the sdk.  I had it outside the main loop before, I guess.  FYI I am using v 2.5.0, if that matters.  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.  And that is it.  

int main(void)

{

    int blink_status = 0;

    int err = 0;

    configure_gpio();

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

    }

RIGHT HERE:   

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

    LOG_INF("Bluetooth initialized");

Another quick question, why would I have trouble flashing my Acconeer examples after flashing an example from the NRF sdk?  They are setup for mcumgr, but should that matter?  I feel like I had this trouble before.  I am flashing the nrf example using jlink through the 52840DK.  Then I go back and try to flash an example from Acconeer and it won't flash with mcumgr or jlink.  My board is setup like the Acconeer xm126, FYI.  

I hope that all makes sense.  Thanks.

Mike

[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