https://devzone.nordicsemi.com/f/nordic-q-a/60665/app_timer-value-affects-twimI&#39;m seeing an odd behavior where the ability for our application to communicate to peripherals via twim is being affected by the initialization values for app timers. Timers are initialized and started before twim. a single shot timer with durationen-USTelligent Community 13Fri, 08 May 2020 19:14:57 GMThttps://devzone.nordicsemi.com/thread/249023?ContentTypeID=1Fri, 08 May 2020 19:14:57 GMT137ad170-7792-4731-bb38-c0d22fbe4515:21e60643-fc97-4ea4-bc65-6a28532b1991Raymond Pelletier<p>Changing the initialization order fixes the problem. &nbsp;Softdevice &gt; timers &gt; TWIM. Works for all values of the timer. If anyone has an explanation of why the original order fails, if one exists, it would be useful to clarify and avoid issues going forward.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/247414?ContentTypeID=1Wed, 29 Apr 2020 18:29:04 GMT137ad170-7792-4731-bb38-c0d22fbe4515:5ade495b-75ce-42c4-9262-7594c6616aa4Einar Thorsrud<p>Hi,</p> <p></p> <p>I cannot see how this change in app timer frequency itself should cause this problem, but from your description, it seems clear that this could change the timing of other things in your system, such as &quot;send info over a bluetooth characteristic or talk to a peripheral via TWIM&quot;. This is clearly where you should look, but I cannot say anything more specific without knowing more about your firmware.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/247408?ContentTypeID=1Wed, 29 Apr 2020 17:35:58 GMT137ad170-7792-4731-bb38-c0d22fbe4515:76cf27c5-f0d5-4a07-8885-f316c0062c60Raymond Pelletier<ul> <li>What does the third timer control (i.e. what happens in the timeout handler)?</li> </ul> <p>It examines the state of the buttons on our device and changes the LED patterns according to UX design rules.</p> <ul> <li>Is the third timer related to your TWIM transactions or handling in some way?</li> </ul> <p>If the button state should trigger anything more elaborate the handler queues&nbsp;an event on the app scheduler. (for example, to send&nbsp;info&nbsp;over a bluetooth characteristic or talk to a peripheral via TWIM)</p> <ul> <li>How is TWIM affected?</li> </ul> <p>a read operation never completes. During initialization we wait for the read to complete before continuing.</p> <ul> <li>Anything else you can say? Please elaborate</li> </ul> <p>The hang occurs during initialization of the device on reset and is the first attempt to communicate over&nbsp;twim. The difference is caused by the change of a single integer configuration value (frequency of the button scan)</p> <p></p> <ul> <li>Can you share code?</li> </ul> <p>I prefer not to.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/246813?ContentTypeID=1Mon, 27 Apr 2020 12:12:53 GMT137ad170-7792-4731-bb38-c0d22fbe4515:7ec407f0-d1f5-4982-a186-026e6b22a062Einar Thorsrud<p>Hi,</p> <p>I do not immediately see any good reason the frequency of an app timer should affect your TWIM transactions in general, particularly not when&nbsp;increasing it. I have some questions:</p> <ul> <li>What does the third timer control (i.e. what happens in the timeout handler)?</li> <li>Is the third timer related to your TWIM transactions or handling in some way?</li> <li>How is TWIM affected?</li> <li>Anything else you can say? Please elaborate</li> <li>Can you share code?</li> </ul><div style="clear:both;"></div>