NRF52 enters DebugMonitor mode by itself when changing RTC frequency

[Andy]

Hello,

I'm having a weird issue that I don't really understand.

I am currently replacing an old timer-based time-keeping implementation for a new RTC-based implementation.

After changing the lowering the frequency of the RTC from 1024 to 32 Hz, the program started getting "stuck" on boot. If I halt the program with JLink I can see that the IPSR is set to 00B (DebugMonitor). If I resume the program again with the run command in JLink, it runs fine, and if I halt it again the IPSR is set to 000 (NoException).

However, if I halt the program once more, I always get a HardFaultMemManage in the ISPR.

Why could the DebugMonitor thing be stopping my program?

EDIT:

I found the cause of my problem not to be the RTC frequency, but another piece of my code that's dependent on the RTC clock.

I have a function that's called like this: while(stm_reset() != NRF_SUCCESS);.

This function basically resets a second STM processor in the same board when the NRF52 boots. That function pulls down the reset pin in the STM, waits 1 ms and pulls it back up. The way I check the time is by using a global timekeeping module that keeps track of the ms passed since boot. Before, I had the timekeeping module running on the app_simple_timer module ticking once every millisecond. Now with the RTC, the module "ticks" every 31.25 ms and I increase the global ms variable accordingly.

When I had the simple timer-based module running at 1 KHz I never had any problems whatsoever. Now I get that DebugMonitor problem. Any ideas?

Btw, if I comment out the reset while loop, everything works fine.

Below is the code for the stm_reset() function for reference. 

ret_code_t stm_reset() {
	static uint32_t reset_timestamp = 0;
	if (reset_timestamp == 0) {
		// Pull the reset pin down, should generate a reset in the STM
		nrf_gpio_pin_write(pins.stm.reset, 0);
		reset_timestamp = clock_get_ms();
	}

	// The STM needs a reset pulse of at least 20 us, we wait ~1 ms
	if (clock_get_ms_since(reset_timestamp) > 1) {
		// Pull the reset pin up, should finalize the reset sequence
		nrf_gpio_pin_write(pins.stm.reset, 1);

		// Reset the time for a future reset
		reset_timestamp = 0;
		return NRF_SUCCESS;
	} else {
		return NRF_ERROR_BUSY;
	}
}

[Vidar Berg]

Hi,

0x0B is the SVCall IRQ, debug mon is 0xC. Does your program still get stuck in this interrupt, and does your program get past ble_stack_init()?

[Andy]

I found the issue. It was that I was calling that function before the BLE stack initialization, and since the RTC requires the SoftDevice to be enabled in order to use the LF clock, it wasn't working.

[Andy]

By the way, how do you know that 0x0B is SVCall IRQ and debug monitor is 0x0C? JLink was showing 00B (DebugMonitor) in the halt output. Where can I find that documentation?

[Vidar Berg]

Thanks for the update. This appears to be a bug in Jlink commander. The 0x0B number is reserved for the SVcall IRQ on all ICs based on the Cortex M4. Documentation of the IPSR register can be found in the generic user guide from ARM (link), and the ISR numbers specific to nRF52 can be found in the nrf52.h/nrf528xx.h header.