app_timer value affects twim?

[Raymond Pelletier]

I'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 duration 20 seconds
• a repeated timer with duration 1 seconds
• a repeated timer with duration of 25 milliSeconds

After setting up GPIO and the softdevice I initialize and enable TWIM

The application works fine until I increase the duration of the third timer from 25 milliSeconds to 100 millSeconds.

At 100 milliSeconds TWIM no longer works.

Can anyone posit a theory as to why this is the case?

I've not been able to confirm whether or not the pin we use for I2C_SCL has a clock signal or not. I'm primarily a software person so my hardware diagnostic skills are pretty basic.

[Einar Thorsrud]

Hi,

I do not immediately see any good reason the frequency of an app timer should affect your TWIM transactions in general, particularly not when increasing it. I have some questions:

• What does the third timer control (i.e. what happens in the timeout handler)?
• Is the third timer related to your TWIM transactions or handling in some way?
• How is TWIM affected?
• Anything else you can say? Please elaborate
• Can you share code?

[Raymond Pelletier]

• What does the third timer control (i.e. what happens in the timeout handler)?

It examines the state of the buttons on our device and changes the LED patterns according to UX design rules.

• Is the third timer related to your TWIM transactions or handling in some way?

If the button state should trigger anything more elaborate the handler queues an event on the app scheduler. (for example, to send info over a bluetooth characteristic or talk to a peripheral via TWIM)

• How is TWIM affected?

a read operation never completes. During initialization we wait for the read to complete before continuing.

• Anything else you can say? Please elaborate

The hang occurs during initialization of the device on reset and is the first attempt to communicate over twim. The difference is caused by the change of a single integer configuration value (frequency of the button scan)

• Can you share code?

I prefer not to.

[Einar Thorsrud]

Hi,

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 "send info over a bluetooth characteristic or talk to a peripheral via TWIM". This is clearly where you should look, but I cannot say anything more specific without knowing more about your firmware.

[Raymond Pelletier]

Changing the initialization order fixes the problem.  Softdevice > timers > 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.