RTC1 IRQ not firing until debugger connected.

RE: RTC1 IRQ not firing until debugger connected.

charles — Fri, 29 Mar 2019 15:01:35 GMT

Continuing the conversation over in

https://devzone.nordicsemi.com/f/nordic-q-a/45512/guarantee-that-softdevice-won-t-wake-the-cpu-up

for anyone following along.

RE: RTC1 IRQ not firing until debugger connected.

Vidar Berg — Fri, 29 Mar 2019 14:22:08 GMT

Hi Charles,

Yes, the startup flow sounds good to me. I can't think of any drawbacks by enabling the Softdevice earlier on startup.

Best regards,

Vidar

RE: RTC1 IRQ not firing until debugger connected.

charles — Fri, 29 Mar 2019 13:41:16 GMT

Thanks for the quick response, Vidar.

I ended up changing our code to enable (but not yet use) SoftDevice before we do anything else, and we no longer explicitly initialize the lfclk via the nrf_drv_clock module.

At this point, the only things we do before enabling SoftDevice are:

Read RESETREAS and save it

Protect our CPU (BPROT, APPROTECT, MPU)

Initialize SEGGER RTT and our log buffers

Load and start the hardware watchdog (since we don't know what nrf_sdh_enable_request actually does)

Enable SoftDevice

Initialize app_timer and gpiote

Start our software watchdog timer

Start talking to peripherals via SPI/TWI and boot the system.

Is this a reasonable startup flow? The RTC1 interrupts now fire as expected, and we don't have a lot of time right now so I'd prefer to not investigate what was wrong with the previous effort if this new approach is better anyway 🙂

Thanks,

Charles

RE: RTC1 IRQ not firing until debugger connected.

Vidar Berg — Fri, 29 Mar 2019 13:24:45 GMT

Hi,

[quote user="nicholsonc"]Update, enabling SoftDevice before we start using app_timer seems to fix the issue. I got an answer recently about app_timer and SoftDevice here, so I guess the answer must be something about how we're sleeping the CPU?[/quote]

The Softdevice starts the low-frequency clock source (crystal or RC oscillator depending on configuration). As a test, could you try to start the LF clock manually at the beginning of main to see if it has the same effect as enabling the Softdevice early, or are you doing this already?

Code to start LF clock:

NRF_CLOCK->LFCLKSRC = 1; // Set clock source to external 32KHz crystal. Change to 0 to use internal RC.
NRF_CLOCK->TASKS_LFCLKSTART = 1;
while (NRF_CLOCK->EVENTS_LFCLKSTARTED == 0);

[quote user="nicholsonc"]When a Nordic rep looks at this, could you also explain in precise detail what sd_app_evt_wait does? Maybe post the code? (I wonder if we're sleeping incorrectly, this is the only time we sleep the chip before SoftDevice is enabled.[/quote]

Calling sd_app_evt_wait is similar to calling the __WFE instruction from the app. The main difference is that sd_app_evt_wait does not return on internal Sofdevice events, only application events.

Best regards,

Vidar

RE: RTC1 IRQ not firing until debugger connected.

charles — Thu, 28 Mar 2019 17:56:16 GMT

Update, enabling SoftDevice before we start using app_timer seems to fix the issue. I got an answer recently about app_timer and SoftDevice here, so I guess the answer must be something about how we're sleeping the CPU?

https://devzone.nordicsemi.com/f/nordic-q-a/45266/ok-to-use-app_timer-before-nrf_sdh_enable_request

RE: RTC1 IRQ not firing until debugger connected.

charles — Thu, 28 Mar 2019 15:52:05 GMT

Note also that if we delete the call to sleep_cpu() and just spin hard at 100% CPU duty cycle, this problem vanishes.

RE: RTC1 IRQ not firing until debugger connected.

charles — Thu, 28 Mar 2019 15:42:23 GMT

Whoops, sorry, I see in nrf_soc.h that sd_app_evt_wait looks like it's hidden behind a service call, so I don't know what it does when SoftDevice is enabled.

When a Nordic rep looks at this, could you also explain in precise detail what sd_app_evt_wait does? Maybe post the code? (I wonder if we're sleeping incorrectly, this is the only time we sleep the chip before SoftDevice is enabled.