HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

RE: HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

Daniel_H — Thu, 04 Apr 2024 15:03:39 GMT

Thank you for your help!

I had to include:
- "ses_startup_nrf_common.s"

- "ses_startup_nrf52840.s"

- "system_nrf52840.c"

also I was getting error messages so I had to add a " .tumb_func" in front of the "afterInitialize:" inside the "ses_startup_nrf_common.s"

RE: HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

Vidar Berg — Thu, 04 Apr 2024 14:16:37 GMT

Looking back at the screenshot you posted earlier, it appears that you are using generic startup files for the Cortex-M. I assume those don't include the device specific IRQs or initialization. I recommend you open a nRF5 SDK project to see which startup files we are using there and use the same ones in your project. You must also include https://github.com/NordicSemiconductor/nrfx/blob/master/mdk/system_nrf52840.c This is invoked by the startup file before branching to main().

RE: HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

Daniel_H — Thu, 04 Apr 2024 13:56:21 GMT

Thank you. I tried including it, but I get following errors that I can't resolve.

RE: HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

Vidar Berg — Thu, 04 Apr 2024 13:30:26 GMT

Strange, I haven't experienced this crash with 5.42a. Another alternative is to read the memory location with nrfjprog:

$ nrfjprog --memrd 0x40

The vector at 0x40 is supposed to contain the address of the CLOCK IRQ's interrupt service routine. Instead it contains 0xd8fd3803, which is an invalid memory address. This explains why you get the fault expcetion whenever the CLOCK IRQ is triggered.

Please try to include this file in your build:

https://github.com/NordicSemiconductor/nrfx/blob/master/mdk/ses_startup_nrf52840.s

RE: HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

Daniel_H — Thu, 04 Apr 2024 12:51:13 GMT

SES 5.42a crashes when I try to read the Memory for more than 2 Byte :/
and on the SES 8.10c the memory looks like this:

How do I know if this is the right address?

RE: HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

Vidar Berg — Thu, 04 Apr 2024 12:32:00 GMT

The startup files are also responsible for defining the interrupt vectors. I suspect the problem may lie here, because the CPU registers show that the program is trying to service the POWER_CLOCK_IRQn when the fault occurs.

Please check if the vector address for the CLOCK IRQ is correct by reading out interrupt vector at 0x40:

RE: HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

Daniel_H — Thu, 04 Apr 2024 12:15:33 GMT

I hope it is not the startup files, but the application starts ^^
I created a project and selected the nRF52840 as Target Device.

These are the CPU registers. I hope this helps

RE: HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

Vidar Berg — Thu, 04 Apr 2024 11:13:20 GMT

Hi Daniel,

I see you are not using the SDK provided startup files, but not sure if that is relevant for the issue. Either way, are you able to select the stack frame highlighted below and then take a screenshot of the CPU registers?

Thanks,

Vidar

RE: HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

Daniel_H — Wed, 03 Apr 2024 14:52:58 GMT

Hello Vidar,

Thank you for your reply.

I tried building the project with SES v5.42a and the same outcome but in the Call Stack a little bit more is shown:

in comparison to the SES 8.10c:

Also here are the source files I use:

How would I go about if I wanted to know if the IRQ triggers the HardFault?

Greetings,
Daniel

RE: HardFault_Handler() gets called after trying to start the LFCLK or HFCLK

Vidar Berg — Wed, 03 Apr 2024 11:08:13 GMT

Hello Daniel,

The nrf_clock_task_trigger() call should not cause a fault exception since it only writes to the CLOCK start task in the CLOCK peripheral. However, the CLOCK IRQ triggered after the clock starts could potentially cause this if there is a problem with interrupt handling. Does the call stack reveal where the fault exception was raised?

If possible, I would recommend you try build your project with SES v5.42a and see if you get the same result. This is the version we used for release testing of nRF5 SDK 17.1.0. You can include /components/libraries/uart/retarget.c to redirect printf to UART.

Best regards,

Vidar