Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Wed, 14 May 2025 11:37:52 GMT

Interesting theory, but my APP_USBD_CONFIG_EVENT_QUEUE_ENABLE is not explicitly defined, but set to 1 in config/nrf52840/config/sdk_config.h and NRFX_USBD_CONFIG_IRQ_PRIORITY is set to 6

The full set of defines I make explicitly regarding USB are:

#define APP_USBD_ENABLED 1

#define APP_USBD_CONFIG_SELF_POWERED 0

#define APP_USBD_CONFIG_SOF_HANDLING_MODE APP_USBD_SOF_HANDLING_INTERRUPT

#define APP_USBD_CONFIG_POWER_EVENTS_PROCESS 0

#define APP_USBD_HID_ENABLED 1

#define APP_USBD_HID_GENERIC_ENABLED 1

#define APP_USBD_STRING_SERIAL globalSerialNumber

#define APP_USBD_STRING_SERIAL_EXTERN 1

#define APP_USBD_STRINGS_MANUFACTURER APP_USBD_STRINGS_MANUFACTURER

#define APP_USBD_STRINGS_MANUFACTURER_EXTERN 1

#define APP_USBD_STRINGS_PRODUCT APP_USBD_STRINGS_PRODUCT

#define APP_USBD_STRINGS_PRODUCT_EXTERN 1

#define NRFX_USBD_ENABLED 1

#define APP_USBD_CDC_ACM_ENABLED 1

The rest are from config/nrf52840/config/sdk_config.h

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Niziak — Wed, 14 May 2025 11:08:42 GMT

Looks like generic case where USB handlers works from USB IRQ (APP_USBD_CONFIG_EVENT_QUEUE_ENABLE is 0) and USB IRQ is higher (<4) than SoftDevice's SVC IRQ (==4).

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Tue, 27 Aug 2024 02:13:31 GMT

My linker file is set up like this:

MEMORY
{
FLASH (rx) : ORIGIN = 0x27000, LENGTH = 0x7d000
RAM (rwx) : ORIGIN = 0x20008000, LENGTH = 0x38000
CODE_RAM (rx) : ORIGIN = 0x808000, LENGTH = 0x38000
}

And this was based on the notes in s140_nrf52_7.2.0_release-notes-update-1.pdf.

The callstack clearly had `sd_clock_hfclk_is_running` in it, which looks like it's going into the SVC.

Is 0x25ed8 not in the soft device memory space?

> it is optional to use two different stacks for interrupts and "main mode", so I'm not sure what your application does.

What flag/code would help identify whether two different stacks are being used?

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Martin Tverdal — Mon, 26 Aug 2024 11:58:05 GMT

Thanks for sharing latest stack frame, Im not able to see anything interesting from it, other than that now the fault seems to happen somewhere in your application (beaus 0x25ed8 is higher than the highest address in s140). or is 0x25ed8 just an adress in your hardfault-handler maybe?

Since it happens on many different boards, and also on pretty fresh boards then I think we can rule out flash-wearing too.

Coretex has concept of two differint stacks, msp and psp. one for "main mode" (also called "thread mode), that cpu is using when it is not handling interrupts, and another callsstack it uses for interrupts. it is optional to use two different stacks for interrupts and "main mode", so I'm not sure what your application does.

But all of the code in Softdevice anyway runs in interrupt mode, since all the calls to Softdevice is implemented as SVC interrupts. And since there is only one callstack for all interrupts, Softdevice and application end up sharing the same callstack.

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Mon, 26 Aug 2024 01:28:16 GMT

Another explanation might be corruption of callstack somehow, maybe you can try increasing the interrupt callstack a bit and see if problem goes away?

Just to make sure I'm not mis-understanding it - is the stack here shared with user and interrupts? Or is interrupts separate?

I use an 8kb stack size on the nrf52840, and the code (minus nrf5 specific stuff) runs on a 2kb stack on another mcu.

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Mon, 26 Aug 2024 01:21:20 GMT

One possible explanation is corruption of the instruction in FLASH itself, does this happen easily for you on many different boards? If you have only reproduced it on only one board, is it possible that you have exhausted the number flash erase cycles nrf52840 supports. From top of my head I think that is 10'000.

To answer this question - this happens on every board I've tested on, some with single digit erase cycles

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Sat, 24 Aug 2024 07:41:17 GMT

I tried this again today, and the `NRF_CLOCK->EVENTS_HFCLKSTARTED == 0` works, but testing with the old sd_clock_hfclk_request() approach again gave me a different callstack:

The call hung, and stopping execution landed on 0x25ed8:

0x00025ed2: mrs r1, MSP
0x00025ed6: ldr r0, [r1, #24]

0x00025ed8: subs r0, #2

0x00025eda: ldrb r0, [r0, #0]

0x00025edc: cmp r0, #16

0x00025ede: blt.n 0x25f08

Sharing this in case it helps at all.

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Martin Tverdal — Fri, 23 Aug 2024 12:53:27 GMT

yes, good point pan-201 should not be a concern for you then!

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Fri, 23 Aug 2024 12:31:08 GMT

Thanks so much for such a detailed reply.

I should clarify -- the device enters a non-responsive state, and loses BLE connections, but doesn't trigger the debugger automatically. If I pause execution, I get that call stack.

Regarding pan-201 -- I see that it's listed in rev1, but not rev2 of the nrf52840. Is it safe to assume pan-201 is not an issue since I'm running on rev2?

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Martin Tverdal — Fri, 23 Aug 2024 10:36:37 GMT

Hi,

I've been looking into this a bit and I'm not sure what the root cause for the crash you see can be.

You seem to be hitting a hardfault/busfault at instruction at 0xac4, that is an instruction inside

the SVC handler in the MBR, master boot record. The function you are calling in the softdevice sd_clock_hfclk_is_running, is implemented as a SVC intrrupt, and the MBR simply forwards it to the Softdevice, and judging by your stack-frame you posted, when the crash happens, it seems like the it hasn't even reached the Softdevice, it crashes inside the MBR, in the code that simply forwards interrupts (including SVC interrupts) to Softdevice.

One possible explanation is corruption of the instruction in FLASH itself, does this happen easily for you on many different boards? If you have only reproduced it on only one board, is it possible that you have exhausted the number flash erase cycles nrf52840 supports. From top of my head I think that is 10'000.

Another explanation might be corruption of callstack somehow, maybe you can try increasing the interrupt callstack a bit and see if problem goes away?

Reading NRF_CLOCK->HFCLKSTAT like you have found to work sounds safe to me, meaning Softdevice doesn't protect NRF_CLOCK peripheral from being read.

So you busy-waiting for that to change to 0x10001 sounds safe in that regards. However, because of pan-201, you might want to switch to NRF_CLOCK->EVENTS_HFCLKSTARTED instead.

That is what the Softdevice will read if you call sd_clock_hfclk_is_running.

So in this sense, I think switching to while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0) is a good solution. However, even if that works, I still have a feeling there is something wrong that might fail in a different way somewhere else.

Best regards,

Martin Tverdal

Softdevice team.

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Mon, 12 Aug 2024 16:28:27 GMT

The value seems right -- `00 10 00 00` bytes at the address. Note that another reason I don't think it's the interrupt disabled issue is that when I replace the sd_clock_hfclk_is_running with my manual register lookup, it all works, despite there being a sd_clock_hfclk_release call later, which should also crash according to that theory.

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Priyanka — Mon, 12 Aug 2024 06:56:58 GMT

Hi,
I was informed by our experts about another suspicion after looking more closely at your callstack contents,
??@0x00000ac4 (Unknown Source:0)

That line there on top of your callstack makes us suspect that the content of address 0x20000000 (so the first address in RAM), has been corrupted somehow.
Please check that before you call sd_clock_hfclk_is_running().
The content should, in your case, always be 00001000. it is that address at which the MBR stores where to forward interrupts and 0x1000 will make MBR forward interrupts to Softdevice.

You can check this, for example, by adding the following code before the call to sd_clock_hfclk_is_running that fails, and see if you get stuck there, and tell us what the value at 0x20000000 is if it hangs there:

if(*((uint32_t*)0x20000000)!=0x1000)
{
while(1);
}

Or maybe you can just connect with debugger and see what content is at 0x20000000 when the program has crashed.

-Priyanka

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Fri, 09 Aug 2024 18:32:58 GMT

So is there any condition under which sd_clock_hfclk_request() or the nrf5 sdk disables irqs? I don't have a single disable_irq in my entire codebase.

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Priyanka — Fri, 09 Aug 2024 08:28:41 GMT

Yes, that is true, unless this code gets interrupted by another interrupt, and that interupt disables irqs for example, and then return.
To demonstrate, you can see this simple program.

void SVC_Handler(void)
{
__disable_irq();
}

void __svc( 10 ) dummy( void ) ;
int main(void)
{
dummy();
__nop();
__nop();
__nop();
__nop();
dummy();
while(1)
{
}
}

It will hardfault on the second call to dummy(), because the first time the SVC handler ran, it disabled interrupts and then returned.

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Fri, 09 Aug 2024 08:08:56 GMT

The flow of the program is:

sd_clock_hfclk_request();

do {

sd_clock_hfclk_is_running(...);

} while (...);

If any SVC interrupt causes a hard fault when called in an interrupt, would it not crash when calling sd_clock_hfclk_request first?

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Priyanka — Thu, 08 Aug 2024 07:51:15 GMT

Hi,

We still feel that there might be some mess-up with svc and interrupt configuration. Maybe you end up at this point, calling sd_clock_hfclk_is_running while you have disabled interrupts then?

The call to all sd_ functions is just implemented as triggering svc interrupts, and when we tried on purpose to do that in a simple program like this, it does hardfault.

-Priyanka

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Mon, 05 Aug 2024 09:55:54 GMT

`sd_clock_hfclk_is_running` is defined as such in the disassembly at that address:

svc 68 @ 0x44
bx lr

The address is just a stub into the soft device.

I don't believe it is ever being called from an interrupt handler (I'm pretty sure it's not, other things would be very problematic in the code path). There is a call right above it which succeeds to the softdevice too: sd_clock_hfclk_request().

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Priyanka — Mon, 05 Aug 2024 08:35:04 GMT

Hi,

From the callstack, it looks like the crash has happened in application and not inside sd_clock_hfclk_is_running, since the address is 0x000276ae, which is outside Softdevice..

One possibility is that you end up calling sd_clock_hfclk_is_running from an interrupt handler that has higher (or equal) priority than SVC priority, that is not allowed by design. If you call any SD function from a interrupt handler like that, it will hardfault.

-Priyanka

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Priyanka — Fri, 02 Aug 2024 17:49:23 GMT

I am yet to hear from them. I will check your suggestion too in the meantime.

-Priyanka

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Thu, 01 Aug 2024 18:42:48 GMT

Is there any other way to avoid the errata other than turning on the hfclk? it'd be nice to avoid the power draw that is associated with this workaround.

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Fri, 26 Jul 2024 19:11:42 GMT

Thanks for the update, looking forward to hearing more!

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Priyanka — Thu, 25 Jul 2024 05:52:07 GMT

Hi,

Apologies for the delay. De to the summer holidays we are understaffed at the moment. I have consulted your issue internally with experts, but please expect a slight delay. I will get back to you as soon as I hear form them.

Thank you for your patience.

-Priyanka

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Fri, 19 Jul 2024 17:37:21 GMT

Can you give an example of how my code to check HFCLK won't function properly? Before, you said the code was correct, now you're saying it may not function properly.

I would like to use the SoftDevice API, but it crashes. So that isn't an option, unless you can advise why it's crashing, and how this can be avoided.

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

Priyanka — Fri, 19 Jul 2024 13:06:55 GMT

Hi,

It's true that the function sd_clock_hfclk_is_running does not change any state, but it simply checks the state of the HFCLK. So let's take a scenario where your HFCLK does not function properly, and this function is also not called, and then it can affect your program. Moreover, if you are not using this function, then you are using direct register checks, and if your HFCLK state is misinterpreted, this can lead to BLE radio issues. So it's always recommended to use the provided SoftDevice API functions to ensure proper operation.

Also, it does depend on your implementation, rather the way you use it in your code according to your needs, can vary depending on your implementation.

-Priyanka

RE: Crash in sd_clock_hfclk_is_running on Soft Device S140, 7.3.0

jthlim — Thu, 11 Jul 2024 12:26:43 GMT

huh? That doesn't make any sense.

This is a query function -- asking is the hfclk running off the xtal -- not something that is meant to change any state. Can you elaborate why BLE radio may not function properly if the register is used to check if hfclk is running vs calling sd_clock_hfclk_is_running?

And how does sd_clock_hfclk_is_running depend on my implementation? This function is provided through SVC by the softdevice.