Bug in setWatch? Cross watching BTN3 and BTN4

Hi everybody,
I have this code:

clearWatch();
setWatch(() => {
  console.log('\-----');
  console.log('BTN3');
  btn3Handler()
}, BTN3, {
  debounce: DEBOUNCE,
  repeat: true,
  edge: "falling"
});
setWatch(() => {
  console.log('BTN4');
  btn4Handler()
}, BTN4, {
  debounce: DEBOUNCE,
  repeat: true,
  edge: "falling"
});

When I press BTN3 I get often (not always) get this in console:

\----
BTN3
BTN4

It looks like BTN4 fires together with BTN3.

The only workaround I found is this ugly one (clear watches before calling the handler and reattach them after):

clearWatch();
setWatch(() => {
  console.log('-----');
  console.log('BTN3');
  clearWatch();
  btn3Handler();
  addWatch();
}, BTN3, {
  debounce: DEBOUNCE,
  repeat: true,
  edge: "falling"
});
setWatch(() => {
  console.log('BTN4');
  btn4handler();
}, BTN4, {
  debounce: DEBOUNCE,
  repeat: true,
  edge: "falling"
});

The issue doesn't happen in the emulator, just on the real clock.

This is the gist with the complete code (the issue is at line 119):
https://gist.github.com/fbedussi/05f7bee30cf7fbc43a3dbfa728c5edb2

Is this a bug or am I missing something?

thanks and kudos for the project!

Thanks for this! I just tried your code though and I'm not seeing the problem at all.

Any chance you're just getting your fingers neat the left-hand side of the screen and that's counting as a button press of BTN4?

there should be a reference to a function e.g.
setWatch(myhandler, BTN4, {edge:"falling", debounce:50, repeat:true});
I'm a the moment a bit unsure whether an arrow function can deliver this. Maybe try an anonymous function().

I tried to make a video to show the bug on the watch, but, surprise! Today I cannot reproduce it any more. Yesterday it was there for sure, but I didn't manage to take a video of it.

This already happened to me and drives me mad: there are sometimes bugs that are just inexplicable and that after a while disappears magically, it looks like there is some sort of cache that after a while expires and clear the bug, is that the case?

BTW @Tx thanks for you reply, but arrow functions are not the cause. They work fine in all other scenarios, and I tried to replace them with anonymous functions, but this didn't solve the issue (when there was a issue).

Sat 2020.05.02

'Yesterday it was there for sure'
'This already happened to me and drives me mad'
'sometimes bugs that are just inexplicable and that after a while disappears magically'

@fbedussi please do not take this the wrong way, but those comments did make me chuckle! Not directed your way, mind you, but at my frustrations over the last several years. In my case I know I am pushing the memory limits of the device to find a solution to a particular task, but with experience I know what I am able to get away with that is, . . . until recently.

Review any of the last ten of my forum conversations maybe first starting with:

Technique needed to notify of low memory condition during runtime

I feel for you fbedussi, as I have had unexplainable intermittent issues recognized for over two years that I'm now convinced, based on reading between the lines of the forum responders, that they are now thinking I'm a 'Nut Job'! So, I see feel and hear your frustration. Please understand mine, two years!

enuf about me. So how does this pertain to your situation?

Thank you for posting your entire code file in your gist link. When I read over the file several things stuck out, and I now am seeing relationships in what issues I have seen and those that you had encountered. I had troubles with the MDBT42Q breakout board, not the Bangle, but they do use the same nRF chip. I documented that two months ago:

Tutorial example output anomaly using low level access PPI

Now plagued with two simultaneous issues, and needed to resolve the latter before I'm able to get back to that thread, but we now have a separate individual that with their own creation is coding in the same procedureal style as I am and using more than one setWatch(). The latter is key here, as persuing the forums for two years, I seemed to be the only one that created a project using two, and issues until about a month ago, when Abhigkar attempted the same, but without entire source code. Now your thread pops up and the similarities and usage that mirror what I've attempted along with nearly identical run time output can no longer remain hidden as it is too coincidental to have three different minds on their own individual projects experience the same conditions. Wouldn't you agree?

I also witnessed the wrong watch firing, or multiple responses when only one was expected. While i've been chasing a memory issue I haven't been back to that post to double check compare with SMT32 boards, but initial tests led me to believe the same outcome. It is time consuming and maddening.

May I ask which PC type and OS you are using? I'm on Windows10

Hi @Robin, thanks for your message. Maybe there is some low level bug somewhere, I'm still experiencing my issue from time to time, even if much less frequently than in the first place.

I'm coding on MacOS, but I don't think this matters that much, since the issue appears only on the physical Bangle.js.

@Gordon I finally managed to get a video of the bug in action:
https://youtu.be/GPwXgH1iBNU

as you can see I'm not touching the screen, the watch is running the code in the gist, clicking BTN3 sometimes causes watches on BTN4 (+ 1 minute) and BTN5 (+ 1 second) to fire

@Robin messing around with the internals of the nRF52 using the NRF52LL library and getting issues with setWatch really doesn't seem to be that related here. Likely in your case it's due to using the same GPIOTE/PPI numbers as Espruino allocates for the setWatch, so just changing those numbers would help.

Thanks for the video @fbedussi - that does seem odd. So you can actually have it working absolutely fine sometimes, and sometimes it does this?

I might have been tempted to blame something in your specific watch hardware, but if there are times that you don't see the issue I wouldn't be too sure.

Is there anything specific that makes this happen? for instance only when you upload via the Web IDE or something like that?

Hi @Gordon basically the behavior is the one shown in the video, the bug shows up once every 10/20 clicks.

I cannot identify anything specific that makes this happen, it happens both with code loaded via IDE and via the app loader.

lines starting with a 'greater than' denote quoted text