# M-SoM Interrupt Issue **URL:** \ **Category:** Firmware\ **Tags:** m404\ **Created:** [November 28, 2024, 3:20am UTC](https://community.particle.io/t/m-som-interrupt-issue/68711 "2024-11-28T03:20:36Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Dean0](https://avatars.discourse-cdn.com/v4/letter/d/82dd89/32.png) [@Dean0](https://community.particle.io/u/Dean0)\ **Post date:** [November 28, 2024, 3:20am UTC](https://community.particle.io/t/m-som-interrupt-issue/68711/1 "2024-11-28T03:20:36Z")
I'm running a relatively simple piece of firmware on the M404 at device OS 5.9.0 which has an interrupt running on a GPIO rising that increments a counter, essentially: attachInterrupt(TEST\_PIN, interruptFunction, RISING); void interruptFunction() { interruptCount++; } When required, I rotate an axle attached to a hall effect sensor, of which the output is to TEST\_PIN. I expect about 120 interrupts per second from this, and most of the time that's exactly what I get. The issue is, sometimes I get 0 interrupts for seemingly no reason (I spin the axle , generating 120Hz, none are picked up or the first x are, but the rest aren't) even though I know for certain that there is a ~120Hz square wave at TEST\_PIN. It's as though the interrupt no longer exists - but if I spin the axel again, there's a 50/50 chance the interrupt will count again. Fortunately, I also have a b5 SoM. If I run the same firmware and the same OS, I have a 100% success rate, it literally works every time vs the 50% success rate I get with the M-SoM. I have also tried (on the M-SoM): - disabling the system thread and switching to manual mode (no cellular), which seemed to boost the success rate to 80-90%. - using thread block (no difference) - using Interrupts() (no difference) - using a falling edge (no difference) Is this a known issue with the M-SoM, or are there any changes I can make to force my interrupt to hit every time like it does with the B-SoM? I appreciate your help. ---
**Author:** ![rickkas7](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rickkas7/32/8681_2.png) [@rickkas7](https://community.particle.io/u/rickkas7)\ **Post date:** [November 29, 2024, 10:33am UTC](https://community.particle.io/t/m-som-interrupt-issue/68711/2 "2024-11-29T10:33:29Z")
I'd try using the atomic functions. Writing the value from the ISR and reading it, presumably from the loop thread. can result in unexpected values. See this post: > [@Can the P2 run two Interrupts concurrently?](https://community.particle.io/t/can-the-p2-run-two-interrupts-concurrently/64493/4): > > I ran a test and the interrupt counts seem to be working for me in the scenario below. I connected a frequency generator to pins D2 and D3. It was set for 1000 Hz. I then ran this firmware on the Photon 2 (it’s a P2 on the Photon 2, so they should behave the same). #include "Particle.h" SYSTEM\_THREAD(ENABLED); SYSTEM\_MODE(SEMI\_AUTOMATIC); SerialLogHandler logHandler; void isrD2(); void isrD3(); std::atomic\ counterD2; std::atomic\ counterD3; void setu… Since the P2 and M-SoM use nearly identical RTL872x processors, I'd try that first. ---
**Author:** ![Dean0](https://avatars.discourse-cdn.com/v4/letter/d/82dd89/32.png) [@Dean0](https://community.particle.io/u/Dean0)\ **Post date:** [December 1, 2024, 11:20pm UTC](https://community.particle.io/t/m-som-interrupt-issue/68711/3 "2024-12-01T23:20:15Z")
Hi Rick, thanks for the reply. I implemented: std::atomic\ interruptCount; void pulseInterrupt() { interruptCount.fetch\_add(1, std::memory\_order\_relaxed); } uint32\_t finalCount = interruptCount.load(std::memory\_order\_relaxed); // for publishing interruptCount4Particle = interruptCount.load(std::memory\_order\_relaxed); // for particle variable interruptCount.store(0, std::memory\_order\_relaxed); // to clear And, unfortunately, I still have sessions where I miss interrupts. For consistency, I flashed the same code and OS onto the b5 SoM, and it never missed a beat (over 50 test runs): ![b5_SoM_publishes](https://us1.discourse-cdn.com/flex026/uploads/particle/original/3X/3/4/34f629063523093a7190313674ef114084145a54.png) Whereas the M404 failed after 9 tests in this instance: ![M404_publishes](https://us1.discourse-cdn.com/flex026/uploads/particle/original/3X/5/2/52dda1a2a61f99c02da5ff3c7dabbeb51c69ed3d.png) It's extremely strange to me that we can't replicate the problem on the b5 SoM. Please let me know if you have any other fixes to try. ---
**Author:** ![rickkas7](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rickkas7/32/8681_2.png) [@rickkas7](https://community.particle.io/u/rickkas7)\ **Post date:** [December 2, 2024, 9:36am UTC](https://community.particle.io/t/m-som-interrupt-issue/68711/4 "2024-12-02T09:36:38Z")
Which pin, and how is it connected? If it's open collector or a SPST switch, are you using an external pull? What size and up or down? ---
**Author:** ![Dean0](https://avatars.discourse-cdn.com/v4/letter/d/82dd89/32.png) [@Dean0](https://community.particle.io/u/Dean0)\ **Post date:** [December 3, 2024, 12:31am UTC](https://community.particle.io/t/m-som-interrupt-issue/68711/5 "2024-12-03T00:31:39Z")
Hi Rick, As part of my reply, I was going to send you screenshots from our oscilloscope - and in doing so, I noticed that the voltage on the hall effect was far lower when using the M404. As it turns out, I the ground pin of the sensor was connected to A4 and not GND this entire time. After I wrote A4 low, the issue was resolved. Apologies for the stuff-up, and thanks for the extra atomic type variable info - we'll use this as part of our firmware going forward. I guess one other takeaway is the surprise that the B5 SoM worked in this scenario! Would you happen to have any idea why? Also, if you have any other in-depth interrupt tips, please share them. Thanks for your help. Also, extra details for anyone else viewing this thread: - The pin was A3, external 10k pull-down - The sensor was a latching push-pull hall effect sensor ---
**Author:** ![rickkas7](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rickkas7/32/8681_2.png) [@rickkas7](https://community.particle.io/u/rickkas7)\ **Post date:** [December 3, 2024, 9:49am UTC](https://community.particle.io/t/m-som-interrupt-issue/68711/6 "2024-12-03T09:49:07Z")
I don't know, but ADC inputs on the RTL872x are much lower in impedance than the nRF52, and I'd guess that probably has something to do with it. ---
**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/particle/original/3X/6/4/64635adccc35238caa19e9b553ec3e98b163d026.png) [@system](https://community.particle.io/u/system)\ **Post date:** [January 2, 2025, 7:49pm UTC](https://community.particle.io/t/m-som-interrupt-issue/68711/7 "2025-01-02T19:49:58Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.