Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

RE: Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

Karl Ylvisaker — Mon, 16 Oct 2023 09:39:55 GMT

Hello Owain,

[quote user="OwainJangor"]I refactored code to do the meaty stuff in a thread; all ISR now does is signal the thread to run. This has allowed turning asserts back on; all seems to be working well at the moment.[/quote]

Thank you for the update - I am happy to hear that you have aligned your code with the best practice for this and that you are no longer having an issue with this! :)

[quote user="OwainJangor"]Main processor is STM, ble processor is Nordic; but it is interesting what you mention about the easyDMA.[/quote]

Aha, I understand. I dont have any personal experience with STM and so I cant speak to their features or capabilities, but in general I can say that the easyDMA indeed is a very useful feature when working with asynchronous memory processes in Nordic devices, at least.

Best regards,
Karl

RE: Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

OwainJangor — Fri, 13 Oct 2023 14:32:04 GMT

Hi Karl,

I refactored code to do the meaty stuff in a thread; all ISR now does is signal the thread to run. This has allowed turning asserts back on; all seems to be working well at the moment.

Main processor is STM, ble processor is Nordic; but it is interesting what you mention about the easyDMA.

Regards,
Owain

RE: Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

Karl Ylvisaker — Fri, 13 Oct 2023 07:52:54 GMT

Hello,

[quote user="OwainJangor"]Is what I have said correct and what is best practise here?[/quote]

You are correct that you should not make blocking calls as part of your ISR.

The general advise here is that you should avoid computationally extensive work or blocking calls in your ISRs - instead, your ISRs should signal for the extensive work to be done as part of a lower priority workthread or similar, to avoid blocking all lower priority interrupts for the duration of the execution.
This especially goes for blocking calls which you can not be exactly certain when will complete, like reception of data from another device.

Something I should also note is that I have seen customers coming from projects with non-Nordic devices that are unaware of the easyDMA feature of the nrF52 and nRF53 series devices which lets you receive data through the serial interfaces without having the CPU actively receiving it - this of course also means that you do not need to use blocking calls to receive your serial data. This also goes for transmission of serial data.

[quote user="OwainJangor"]Did anything happen n discord?[/quote]

The Zephyr Discord is open to join, and so if Sarvesh does not come back with a reply here you could join the server yourself and look for the thread on this matter :)

Best regards,
Karl

RE: Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

OwainJangor — Mon, 09 Oct 2023 22:42:07 GMT

I too have just been stung by this one.

I know for other RTOSs' that one is not allowed to make blocking calls in ISR's; this is normal; I just am not sure for this Zephyr OS case.

If the meat of the interrupt processing is being done from a worker thread; then I assume you can make blocking calls? This is the way the original driver for the SPI peripheral I am working with worked. GPIO Interrupt fired; ISR disabled further interrupt and posted job to workqueue where SPI transceive (which make a blocking call) is called.

But driver I have has been hacked and now the SPI transceive is being called directly from the ISR. In fact the GPIO interrupt fires and the our SPI handler is called directly from interrupt context.

As part of a merge of my code to this branch; the branch picked up CONFIG_ASSERT=y from my branch; hence the issue being revealed to me.

Is what I have said correct and what is best practise here?

I can see 2 design possibilities here....

1) ISR processes the peripheral to "clear down" interrupt and posts the result to a worker thread for further processing.

2) As in original driver ISR just disables peripheral interrupt and posts a job to the worker thread. All processing to be done at task/thread level.

If ISR is to do any real work it needs to do SPI transactions to access peripheral registers; and we hit this assert.

Could you advise? Did anything happen n discord?

RE: Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

Karl Ylvisaker — Fri, 21 Jul 2023 12:55:54 GMT

[quote user="Sarvesh"]Thanks Karl [/quote]

No problem at all, I am happy to help! :)

[quote user="Sarvesh"]Actually disabling the ASSERT is not a best practice to follow. [/quote]

I agree with this, especially so since you might be missing other important asserts during your development as well.

[quote user="Sarvesh"]It would be great if you can give some input or get [/quote]

I would recommend that you go into the Zephyr Discord directly to ask their input on this - this way you can faster get the help you need with this.

Best regards,
Karl

RE: Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

Sarvesh — Fri, 21 Jul 2023 09:05:53 GMT

Thanks Karl , It would be great if you can give some input or get . Actually disabling the ASSERT is not a best practice to follow.

RE: Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

Karl Ylvisaker — Fri, 21 Jul 2023 08:35:06 GMT

Thank you for clarifying, the assertion here happens due to the SPI attempting to wait indefinitely for the semaphor in the ISR context, which is not allowed.

"The kernel does allow an ISR to take a semaphore, however the ISR must not attempt to wait if the semaphore is unavailable" this SPI driver cannot work."

Since this is an issue with the Zephyr's SPI context I would raise the question in the Zephyr Discord, to ask what the best practice for working around this would be.
The quickest and simplest solution to this issue would probably be to modify the K_FOREVER to K_NO_WAIT, but I would not generally recommend making changes to the drivers and infrastructure directly without having consulted the Zephyr community first.

Best regards,
Karl

RE: Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

Sarvesh — Fri, 21 Jul 2023 07:48:03 GMT

Sure I have enabled the assertion - this is the assert I am getting when hardfault

00> ASSERTION FAIL [((arch_is_in_isr() == 0) || ((timeout).ticks == (((k_timeout_t) {0})).ticks))] @ WEST_TOPDIR/zephyr/kernel/sem.c:121
00>
00> [00:00:00.772,216] <err> os: r0/a1: 0x00000004 r1/a2: 0x00000079 r2/a3: 0x00000004
00> [00:00:00.772,247] <err> os: r3/a4: 0x00000079 r12/ip: 0x20003064 r14/lr: 0x0002ce89
00> [00:00:00.772,247] <err> os: xpsr: 0x41000021
00> [00:00:00.772,277] <err> os: Faulting instruction address (r15/pc): 0x00033d24
00> [00:00:00.772,308] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
00> [00:00:00.772,338] <err> os: Fault during interrupt handling
00>
00> [00:00:00.772,399] <err> os: Current thread: 0x20002df8 (idle)
00> [00:00:01.100,646] <err> fatal_error: Resetting system
00> *** Booting Zephyr OS build v3.3.99-ncs1 ***

RE: Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

Karl Ylvisaker — Thu, 20 Jul 2023 15:34:53 GMT

Hello,

I am glad to read that this is not an issue for you anymore, but I am still curious which ASSERT it was that triggered?
In general that asserts are added as guardrails for you to hit during development, so that the condition will not be an issue in release. I would therefore suggest that we take a closer look at the specific assert that triggered in this case, so that we can ensure that it is not something that will come back to cause trouble for you later in the development.
In general it is not recommended to perform calls that could be blocking (or otherwise lengthy) as part of an event handler.

Best regards,
Karl

RE: Facing HardFault issue while using SPI peripheral in any callback function in nrf Connect SDK 2.4.0

Sarvesh — Thu, 20 Jul 2023 12:43:40 GMT

Hi , Thanks for help but I have resolved the issue , I just have to disable the

CONFIG_ASSERT=n

in the prj.conf file of project

We can close this now