This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Fatal error unhandled interrupt when using callback with nrfx_pwm_init

Hi Nordic,

Recently we've been working on using the PWM library (nrfx_pwm library) to talk with WS2812C LEDs. This works great.

Now we want to add some callbacks to signal to (our own) library that the LEDs are once again ready for more transactions, I try to do so by passing a callback and semaphore with nrfx_pwm_init like so:

`nrfx_pwm_init(&pwm1, &cfg, ws2812_driver_nrfx_cb, &sem);`

Sadly this seems to result in an unhandled interrupt after a playback, full error below:

`[18730.11h.11m.21s.904] [00:00:05.002,777] <err> os: >>> ZEPHYR FATAL ERROR 1: Unhandled interrupt on CPU 0
[18730.11h.11m.21s.904] [00:00:05.002,807] <err> os: Current thread: 0x20010e28 (unknown)
[18730.11h.11m.21s.904] [00:00:05.018,188] <err> fatal_error: Resetting system`

This seems to happen immediately after the playback has finished, hinting that the interrupt is working properly, but the handling of it is not.

I'm using Nordic SDK v1.5.0 with Zephyr.

In the prj.conf I removed the initialization of the PWM in zephyr and instead manually enable the first PWM like so:

`CONFIG_PWM=n
CONFIG_NRFX_PWM0=y`

This saves me one additional uninit call before calling the init. This does not seem to affect the hardfault behaviour.

Kind regards,

Thom

Parents Reply
  • Thank you! this did help a lot in getting the COMP interrupts to work in nRF Connect SDK.

    Can you perhaps elaborate or give an example on how the IRQs are set up in a safe way using IRQ_DIRECT_CONNECT()?

    As it is suggested to "implemented in such a way that it is safe to put them directly in the vector table. For ISRs written in C, The ISR_DIRECT_DECLARE() macro will do this automatically"

    Is the ISR_DIRECT_DECLARE() macro enough or or other steps necessary to stay safe?

Children
Related