App timer hard fault when running without debugger

RE: App timer hard fault when running without debugger

Vidar Berg — Thu, 02 Mar 2023 13:41:53 GMT

When you get a hardfault, does the program end up in the HardFault_Handler() function? I do not understand what it could be that causes a hardfault when don't have BLE or constant latency mode enabled.

[quote user="Keith V"]I had turn all that off trying to get lower power to work, I'm seeing 500ua average with no advertising. So I'm back to that issue[/quote]

500 uA indicates that a peripheral is requesting the HF clock source in idle. You will also get this if you still have constant latency enabled. Do you have any peripherals apart from RTC enabled in this test?

RE: App timer hard fault when running without debugger

Keith V — Wed, 01 Mar 2023 15:15:39 GMT

Adding NRF_POWER->TASKS_CONSTLAT = 1; does fix the hard fault, the decoupling caps are correct.

But, the real problem is I had all that BLE code commented out When I turn it back on I don't get hard faults either.

I had turn all that off trying to get lower power to work, I'm seeing 500ua average with no advertising. So I'm back to that issue

RE: App timer hard fault when running without debugger

Vidar Berg — Tue, 28 Feb 2023 13:03:09 GMT

Hi,

As a test to help narrow down the problem, can you please try to enable the constant latency power mode (Sub power modes) at the beginning of main() to see if it has the same effect as running the chip in debug interface mode?

Constant latency mode can be enabled by writing the following register (Note: must be done prior to softdevice enable):

 int main(void)
 {
        NRF_POWER->TASKS_CONSTLAT = 1;
        ...

I wonder if what you are seeing could be related to wrong decoupling capacitors on your board, same as discussed in this thread: RE: Wierd hardfault . This could explain why you are not experiencing the issue in debug interface mode, as this mode will prevent the chip from entering its lowest power saving modes.

Best regards,

Vidar