# Photon and Core firmware updates cause code malfunction using interrputs (for a touch project)

**URL:** <https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626>\
**Category:** Firmware\
**Created:** [October 16, 2015, 2:23pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626 "2015-10-16T14:23:06Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![mmowaffak](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mmowaffak/32/6986_2.png) [@mmowaffak](https://community.particle.io/u/mmowaffak)\
**Post date:** [October 16, 2015, 2:23pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/1 "2015-10-16T14:23:06Z")

</div>

Hey

I’m creating a touch sensor using captouch library (imported from Paul Badger’s arduino library). It worked pretty well on the Spark Core using version 0.3.4 for the firmware. After flashing using the newest firmware (0.4.5 or 0.4.6) it doesn’t work at all, i mean nada , nothing! Exact same hardware and code completely different outcomes.

The photon on the other hand is not working properly using all firmware versions, even using the 0.3.4 didn’t get it to work.

The library is here : [https://github.com/lbt/captouch](https://github.com/lbt/captouch) and includes the usage of interrupts.

Is there anything i’m doing wrong here? is using a certain firmware for FLASHING the core or photonn going to affect how they run?

Any help here is appreciated cause i’m going crazy here 😄 Thanks

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [October 16, 2015, 2:46pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/2 "2015-10-16T14:46:06Z")

</div>

Can you activate debugging for the lib

```auto
 #define CAPTOUCH_DEBUG

```

and see what it reports (`Serial.begin()` is required too)?

One other thing you could try to add a `pinMode(m_sensorPin, INPUT);` before `attachInterrupt()` and on a Photon keep in mind

> [@](#):
>
> Photon: All pins with the exception of D0 and A5 (since at present Mode Button external interrupt(EXTI) line is shared with D0, A5). Also please note following are the pins for which EXTI lines are shared so only one can work at a time:  
> D1, A4  
> D2, A0, A3  
> D3, DAC  
> D4, A1

Also try to add some way (e.g. blink D7 LED) to see if your ISR actually gets called.

_ **And** _ make sure to mark `unsigned long CapTouch_tR = 0;` as `volatile` as the optimizer might interfere otherwise.

---

<div class="post-metadata">

**Author:** ![mmowaffak](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mmowaffak/32/6986_2.png) [@mmowaffak](https://community.particle.io/u/mmowaffak)\
**Post date:** [October 18, 2015, 1:51am UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/3 "2015-10-18T01:51:43Z")

</div>

Thanks @ScruffR for the reply really appreciate it. I will try your suggestions out asap and see what I can find. I was wondering though whether these added lines of code should be added in the first place since the same code without them works. That returns me to the original assumption that the new firmware actually does affect the way the code works. Is my assumption wrong?

also i don't quite get what you mean by this part :

> [@ScruffR](#):
>
> Photon: All pins with the exception of D0 and A5 (since at present Mode Button external interrupt(EXTI) line is shared with D0, A5). Also please note following are the pins for which EXTI lines are shared so only one can work at a time:D1, A4D2, A0, A3D3, DACD4, A1

Thanks for all you help 😄

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [October 18, 2015, 2:05pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/4 "2015-10-18T14:05:12Z")

</div>

It’s quite possible (maybe even likely) that the new version (in connection with altered build farm settings - e.g. for the optimizer) caused this behaviour.  
But if any of my assumptions above are correct it’s not a regression you see, but an effect where - excuse the wording - “poor” coding style got punished now, where it should have been already back then.

As for the quote from the docs, it just cautions us not to use any of the pins sharing external interrupt lines.  
These pins should **_not_** be used as interrupt pins in combination (e.g. never `attachInterrupt()` for both D1 **_and_** A4 at the same time).  
Other combinations and IO modes should not be affected tho’.

---

<div class="post-metadata">

**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\
**Post date:** [October 18, 2015, 3:42pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/5 "2015-10-18T15:42:13Z")

</div>

Hi @mmowaffak

Sorry to hear about this regression moving from 0.3.4 to 0.4.x on the Core. We’ll tackle the Core first before focusing on the Photon, since we know that has definitely worked.

First, be sure to try the `volatile` fix that @ScruffR mentioned. If that doesn’t help then please let me have a short test case and instructions for testing so that I can reproduce the problem.

Thanks 😄  
mat

---

<div class="post-metadata">

**Author:** ![Areezo](https://avatars.discourse-cdn.com/v4/letter/a/47e85d/32.png) [@Areezo](https://community.particle.io/u/Areezo)\
**Post date:** [January 25, 2016, 12:27pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/6 "2016-01-25T12:27:34Z")

</div>

hello,

I would like to know if you find any solution for the captouch library on photon using the new firmware. since i’m having the same issue and i don’t know what to do about it.

Many thanks.

---

<div class="post-metadata">

**Author:** ![lbt](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/lbt/32/2557_2.png) [@lbt](https://community.particle.io/u/lbt)\
**Post date:** [May 24, 2016, 11:28am UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/7 "2016-05-24T11:28:19Z")

</div>

I didn’t see this topic previously but as it happens I’m going to try to move my Spark to a modern-ish firmware (0.4.9 I think as 0.5.0 seems to have some issues for me at first look) so I’ll try and do some updates soon.

I’ve alreadyadded the volatile declaration that @mdma suggested (yep, obvious really but I’m not used to interrupt handling 🙂 )  
It seems I had some local smoothing changes which never got pushed so I’ll test they are working and push them to github too.

(as an aside to all this - the touch system was working really well for about 18 months until the cloud compiler went down last week and then two of my Sparks spontaneously reflashed to Tinker (!) and I had to start relearning how to build/flash them. They were both installed - one in a cupboard and one in a box in the garden - so it really wasn’t something local).

(edit to add: oh, I don’t have a photon yet so can’t test on that … maybe soon)

---

<div class="post-metadata">

**Author:** ![lbt](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/lbt/32/2557_2.png) [@lbt](https://community.particle.io/u/lbt)\
**Post date:** [May 25, 2016, 4:24pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/8 "2016-05-25T16:24:32Z")

</div>

Update … this is now working just fine on 0.5.0 using the ‘master’ branch… yay … I can get out of my house again! 😄

There is a core-pre-0.4.7 (which I think is when the std::function\<void()\> went into the firmware?

If there turn out to be core/photon differences then let me know and I’ll put some ifdefs in

---

<div class="post-metadata">

**Author:** ![Colin1](https://avatars.discourse-cdn.com/v4/letter/c/ecb155/32.png) [@Colin1](https://community.particle.io/u/Colin1)\
**Post date:** [August 10, 2016, 7:35pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/9 "2016-08-10T19:35:47Z")

</div>

Hello! This conversation seems to have been a while ago. I am desperately trying to use my photon’s pins as capacitive touch sensors. I have tried all of the library’s mentioned here, as well as following this: [http://jvs.me/spark-core/touch-sensing-on-the-spark-core/](http://jvs.me/spark-core/touch-sensing-on-the-spark-core/)

It seems as though most of these libraries cause my photon to lose connection (after about 10 seconds of flashing any of this code, LED flashes green). Has there been a work around developed for capacitive sensing on the latest photon firmware as of yet?

Thanks!

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [August 10, 2016, 7:48pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/10 "2016-08-10T19:48:52Z")

</div>

> [@Colin1](#):
>
> It seems as though most of these libraries cause my photon to lose connection (after about 10 seconds of flashing any of this code, LED flashes green).

This is usually due to the code starving the cloud tasks of processing time.  
In the code referenced in the link you provided this might be most likely in this loop

```cpp
        digitalWrite(sPin,HIGH);
        do
        {
            // wait for transition
        } while (digitalRead(rPin)==LOW); // if this doesn't happen in time cloud connection will be dropped

```

Possible reasons might be some missing/wrong wiring.  
Possible workaround for the disconnect issue is using `SYSTEM_THREAD(ENABLED)` (not available on a Core) or adding `Particle.process()` inside the loop (might add too much latency to the measuring) or adding a timeout as second condition to leave the loop.

---

<div class="post-metadata">

**Author:** ![Colin1](https://avatars.discourse-cdn.com/v4/letter/c/ecb155/32.png) [@Colin1](https://community.particle.io/u/Colin1)\
**Post date:** [August 10, 2016, 10:01pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/11 "2016-08-10T22:01:31Z")

</div>

Thank you ScruffR,

At first I thought there was a problem with my photon, but it does seem to be a wiring issue. I’ve gotten it to work as I had hoped!

---

<div class="post-metadata">

**Author:** ![Colin1](https://avatars.discourse-cdn.com/v4/letter/c/ecb155/32.png) [@Colin1](https://community.particle.io/u/Colin1)\
**Post date:** [August 15, 2016, 9:50pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/12 "2016-08-15T21:50:07Z")

</div>

Hello again,

it seems as though my setup works 70% of the time, but for some mysterious reason 30% of the time I’m running my code (wiring remaining constant) the time delay readout actually goes DOWN (about 20 microseconds according to serial output) instead of up with I touch the surface. This is a consistently flakey behavior I have noticed through the last several days, and it seems to happen randomly after I re-flash (the same!) firmware to the particle. The other 70% of the time contact increases the signal delay reading about 400-500 microseconds as expected.

If anyone has had these problems I would love some insight! Thanks!

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [August 16, 2016, 8:00am UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/13 "2016-08-16T08:00:14Z")

</div>

Just a wild guess, but could static charge play a role here (socks on carpet ;-))?  
Are you doing multiple measurements or single shot?

---

<div class="post-metadata">

**Author:** ![Colin1](https://avatars.discourse-cdn.com/v4/letter/c/ecb155/32.png) [@Colin1](https://community.particle.io/u/Colin1)\
**Post date:** [August 16, 2016, 2:20pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/14 "2016-08-16T14:20:37Z")

</div>

I’m taking my measurements on a hardwood table and the floor is also hardwood.

I have a wire plugged into the same node as the right leg of the capacitor shown in this schematic: [http://jvs.me/wp-content/uploads/2014/07/SparkCore\_touch\_sense\_bb.png](http://jvs.me/wp-content/uploads/2014/07/SparkCore_touch_sense_bb.png), which is soldered onto a piece of copper tape (so to your question, one measurement/touch point). I’m interested in learning why you think static charge may play a role, and why this would show a decrease in signal delay time.

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [August 16, 2016, 7:22pm UTC](https://community.particle.io/t/photon-and-core-firmware-updates-cause-code-malfunction-using-interrputs-for-a-touch-project/16626/15 "2016-08-16T19:22:06Z")

</div>

You are measuring the time a known cap takes to charge/discharge when exposed to a _known_ charging voltage.  
A physical _neutral_ touch would change (normally increase) the sum capacitance and hence the time to charge/discharge.  
But the key here is that you’d need a known charging source and a neutral (uncharged) touching object.  
When you yourself are “importing” a static charge into the system (e.g. on your finger tips) the first (few) measurement(s) will give you inconclusive results since you got two sources charging/discharging the cap.