SoftDevice Assert Issue in nRF52 Mesh SDK 5.0 with UART Communication

[duanpv]

Dear Nordic Support Team,

I am encountering an issue with the nRF52 SDK for Mesh v5.0 and nRF52 SDK v17.0.2 while running the serial example. The system runs for a while, but then it crashes with a SoftDevice assert error. After the error occurs, the nRF52 no longer responds to any commands sent via UART.

System Configuration:

• nRF52 SDK for Mesh: v5.0
• nRF52 SDK: v17.0.2
• SoftDevice: Enabled
• UART TX Pin: 29
• UART RX Pin: 30
• ECDH: Disabled

<t:    7045378>, net_packet.c,  228, Unencrypted data: : 00015E6CA4DD86A7E07F0F  
<t:    7045384>, transport.c, 1045, Message decrypted  
<t:    7045796>, net_packet.c,  228, Unencrypted data: : C0005E140028DC8990C2C89CC0D9  
<t:    7078353>, net_packet.c,  228, Unencrypted data: : 00015E2FFAD4F333EADBE7  
<t:    7078359>, transport.c, 1045, Message decrypted  
<t:    7078752>, net_packet.c,  228, Unencrypted data: : C0005E514F261ADB62B2CB7F3FB1  
<t:    9442524>, app_error_weak.c,   96, Softdevice assert: 88080:0  

[Edvin]

Hello,

Does this also happen in the unmodified sample applications?

Do you have anything particular in your application? Do you use any peripherals other than UART? What interrupt priorities are you using? I believe that you need to have all your peripherals using the same interrupt priority, and that it needs to be the same priority as the Mesh stack. Can you please make sure that they are?

Best regards,

Edvin

[duanpv]

Dear Edvin,

Thank you for your response.

Due to specific hardware constraints on my custom PCB, I had to adjust certain configurations in the serial example. Therefore, I cannot test with the unmodified example. The modifications I made are necessary to match my hardware design, including:

1. UART pin configuration (in pca10040.h):

#define RX_PIN_NUMBER  30  
#define TX_PIN_NUMBER  29  
#define CTS_PIN_NUMBER 7  
#define RTS_PIN_NUMBER 5  
#define HWFC           false  

2. Disabled ECDH offloading (in main.c):

ERROR_CHECK(mesh_opt_prov_ecdh_offloading_set(false));

3. Changed LF clock source to internal RC oscillator (in sdk_config.h):

#define NRF_SDH_CLOCK_LF_SRC 0  
#define NRF_SDH_CLOCK_LF_RC_CTIV 16  
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 16  
#define NRF_SDH_CLOCK_LF_ACCURACY 1  

4. Adjusted mesh configuration parameters (in nrf_mesh_config_app.h):

#define DSM_SUBNET_MAX 8  
#define DSM_APP_MAX 8  
#define DSM_DEVICE_MAX 48  
#define DSM_VIRTUAL_ADDR_MAX 1  
#define DSM_NONVIRTUAL_ADDR_MAX 64  

5. Enabled PA/LNA using GPIOs (configured in main.c):

Configured sd_ble_opt_set(BLE_COMMON_OPT_PA_LNA, &ble_pa_lna_opts);
Enabled mesh_pa_lna_gpiote_enable(&m_pa_lna_params);

Configured sd_ble_opt_set(BLE_COMMON_OPT_PA_LNA, &ble_pa_lna_opts);

Enabled mesh_pa_lna_gpiote_enable(&m_pa_lna_params);

Aside from these hardware-required changes, the code remains the same as the original serial example.

The issue does not happen immediately but occurs randomly after a few minutes or even several hours of operation. I would appreciate your insights into what might be causing this issue.

Best regards,

duanpv

[Edvin]

Can you please try to set NRF_SDH_CLOCK_LF_RC_TEMP_CTIV to 2? This is required to get the 500ppm accuracy that you are setting using NRF_SDH_CLOCK_LF_ACCURACY 1.

Does that change anything regarding the assert?

Best regards,

Edvin

[duanpv]

Dear Edvin,

After changing NRF_SDH_CLOCK_LF_RC_TEMP_CTIV from 16 to 2, the assert issue seems to be resolved. Thank you for your suggestion!

However, I am now trying to switch to NRF_CLOCK_LF_SRC_SYNTH by modifying my configuration as follows:

#define NRF_SDH_CLOCK_LF_SRC 2  // Use synthesized clock  
#define NRF_SDH_CLOCK_LF_RC_CTIV 0  
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0  
#define NRF_SDH_CLOCK_LF_ACCURACY 1 

With this setup, the system does not start at all. Do I need to change anything else to properly use NRF_CLOCK_LF_SRC_SYNTH?

Best regards,

duanpv

[Edvin]

Hello,

I thought it would do so on it's own, but probably not. You need to start the HFCLK. Try running:

NRF_CLOCK->EVENTS_HFCLKSTARTED=0;

NRF_CLOCK->TASKS_HFCLKSTART=1;
while (NRF_CLOCK->EVENTS_HFCLKSTARTED==0)
{
    // Wait...
}
// Now the HFCLK should be running. 

But: Why do you want to use the NRF_CLOCK_LF_SRC_SYNTH? This will synthesize the LFCLK using the HFCLK. It will cause the current consumption to increase quite a bit, because the HFCLK needs to be running all the time. 

Best regards,

Edvin