s132_nrf52_3.0.0 endless loop at 0x16cbc

[Olaf]

Hello, I'm experiencing frequent endless loops at 0x16cbc with s132_nrf52_3.0.0 softdevice and SDK 12.3 on a custom board with Aconno NRF52832 module. I'm using SAADC and UART peripherals.

SAADC and UART are working with IRQ level 7. As I don't have a tracer available, do you have a hint what is causing the issue?

[Andre]

Does this happen during initialisation? Then it's possible your module does not contain a low frequency crystal. Can you adjust your low frequency clock source to RC or SYNTH, and see if the problem persists? 

[Olaf]

The problem occurs after some minutes and it doesn't occur if I don't initialize the peer manager (I didn't test this over hours) . The clock source is set by

#define NRF_CLOCK_LFCLKSRC      {.source        = NRF_CLOCK_LF_SRC_RC,            \
                                 .rc_ctiv       = 16,                                \
                                 .rc_temp_ctiv  = 2,                                \
                                 .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM}

[tesc]

Hi,

Can you remove the .xtal_accuracy and see if that works? The default .xtal_accuracy setting (of NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM == 0) would usually do.

If you still see the issue, when does this happen? What SoftDevice API calls has your application recently called, what is the SoftDevice configuration, does it happen during advertising, scanning, connection, etc?

Regards,
Terje

[Olaf]

Hi, Terje,

when not initializing the peer manager I don't run into this issue, but get a fatal error at 0x1089e after the advertising timeout. I'm restarting the advertising and do a stop / start of scanning when advertising times out.

/**@brief Function for initiating scanning.
 */
static void scan_start(void)
{
	NRF_LOG_INFO("Scanning\r\n");NRF_LOG_FLUSH();

	ret_code_t err_code;

	err_code = sd_ble_gap_scan_stop();

	err_code = sd_ble_gap_scan_start(&m_scan_params);

	APP_ERROR_CHECK(err_code);

	NRF_LOG_INFO("Scanning\r\n");
}

/**@brief Function for starting advertising.
 */
static void advertising_start(void)
{
	uint32_t err_code = ble_advertising_start(BLE_ADV_MODE_FAST);

	APP_ERROR_CHECK(err_code);

	scan_start();
	APP_ERROR_CHECK(err_code);
}

It occurs after requesting a huge amount of data from a connected GSM modem via UART.

I'm always advertising and scanning. The request is sent and after that the loop is entered. The request is done every 10 seconds without problems until the advertising timeout occurs. I'm not sure if it is exactly at that time, but close to.

I have tried RC, SYNTH and XTAL clock source so far with different settings. The modules datasheet specifies the XTAL accuracy as 100ppm. With XTAL, accuracy at 100ppm and disabled peer manager the system was working the whole day today without fatal error at 0x1089e. I now enabled the peermanger again and the fatal error at 0x1089e occured after about 6 minutes wíth this call stack:

Thread #1 57005 (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)	
	app_error_save_and_stop() at app_error.c:141 0x22034	
	app_error_fault_handler() at main.c:2.482 0x2da84	
	softdevice_fault_handler() at softdevice_handler.c:118 0x3695a	
	<signal handler called>() at 0xfffffff1	
	0x108a0	
	0x10864	

[tesc]

Hi,

Interresting. Can you provide a minimal example having this behavior, that we can use to reproduce the issue?

You write that this might be correlated to advertising timeout, and also that you restart both advertising and scanning at that point. Is there any reason for restarting? Would it be an acceptable workaround to advertise and scan indefinitely?

Regards,
Terje

[Olaf]

Hi,

the issue is caused by the SAADC driver. I have disabled the ppi channel and wrote my own sample function using blocking mode. With this setup the software is stable. Nevertheless I will provide an example to reproduce the issue.

BR

Olaf

[tesc]

Hi,

I am happy to hear that you found have found a workaround!

An example reproducing the issue would be great, as that will enable us to hunt down this bug (it may still be present in the SAADC driver and/or present SoftDevices.)

Regards,
Terje