RE: Kscan callback triggers fault during interrupt handling

adelebrown68 — Mon, 24 Apr 2023 08:32:47 GMT

When I added Micro-ROS to the software stack, the interrupts started causing the halting error below when the first interrupt is triggered.

papa's games

RE: Kscan callback triggers fault during interrupt handling

nategreco — Sat, 18 Mar 2023 18:45:47 GMT

Hello Hakon,
I believe the increase of CONFIG_MAIN_STACK_SIZE may have resolved my issue as I have not seen it. I will re-open if I encounter again, thanks for the help.

RE: Kscan callback triggers fault during interrupt handling

Håkon Alseth — Mon, 13 Mar 2023 15:12:25 GMT

Hi,

[quote user=""]Application is communicating with a touch controller (FT5336) over I2C and registering a callback with kscan_config() and kscan_enable_callback(). Every few minutes a "ZEPHYR FATAL ERROR 0: CPU exception on CPU 0" (Fault during interrupt handling) occurs, restarting the application. Using debug I can see two "<signal handler called>" (photo'd) and I always see a call to "i2c_dump_msgs()" as the lowest call.[/quote]

The functions you're calling are effectively these, as you're selecting the FT5336 device:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.2.99-ncs2/drivers/kscan/kscan_ft5336.c#L223-L225

I would recommend that you first adjust your CONFIG_MAIN_STACK_SIZE to a higher value, for instance 4096.

If you still see assertions, you should scope your SDA/SCL pins using a logic analyzer to see if the communication is working towards your sensor.

[quote user=""]Not sure if it's related by occasionally see "<err> i2c_nrfx_twim: Error on I2C line occurred for message 0" in my application at roughly the same frequency, although I do not see this at the same time as the CPU fault.[/quote]

This normally means that it has problems communicating on that specific address:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.2.99-ncs2/drivers/i2c/i2c_nrfx_twi.c#L131

[quote user=""]I've read similar posts that say this issue arises when an interrupt interrupts an interrupt - Am I understanding that correctly? If so, shouldn't interrupt priorities avoid this? Where/how is this managed? Also worth noting this application uses bluetooth soft device, timers (rtc2), uart, pwm, etc.[/quote]

Are you experiencing the same problems if you isolate the functionality towards this specific sensor?

Kind regards,

Håkon