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


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 : 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 :smile: Thanks

1 Like

Can you activate debugging for the lib


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

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.


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 :

Thanks for all you help :smile:

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’.

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 :smile:

1 Like


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.

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 :slight_smile: )
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)

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

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

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:

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?


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

            // 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.

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!

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!

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

1 Like

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:, 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.

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.

1 Like