Is there a possible clash of RTC1 usage?

[seajayshore]

I have an mBed application that uses the S130 SoftDevice and polls data from a couple of other connected peripherals via I2C & SPI.

I use a Ticker object, which seems to basically be a wrapper around the Nordic app_timer implementation and exposes RTC1 ticks to my application. This single Ticker is used to control polling & other timings across the application.

Every now and then the application-level stuff becomes unresponsive (and a hard reset is needed to make it work again) but the Softdevice is definitely running underneath & the hardware remains connected to whatever app I'm using.

I suspect some sort of collision or missed RTC1 interrupt from the Ticker implementation which then leaves the all hardware & timer interrupts to never get reset.

My question is to anyone more familiar with RTC1 usage (and ideally mbed). Does my interrupt miss/collision theory sound plausible? Where should I look for other uses of RTC1 and things that could interrupt it?

Would an SPI device triggered via a hardware IRQ line possible collide with a timer interrupt & cause it not to set?

[bjorn-spockeli]

I am pretty confident that an interrupt from the SPI peripheral will never collide with an interrupt from the RTC0 peripheral if they occur at the same time, this is taken care of by the peripheral bus.

I am not that familiar with mBED, but if the SoftDevice is still running then I think this is due to some unhandled error somewhere in your application. The SoftDevice only uses RTC0 so it cannot be tha cause of the issue. This could also be a bug in the Ticker implementation.

I think that I would be a good idea to post this on the mBED forum as there are'nt that many mBED users here on DevZone.

Bjørn

[bjorn-spockeli]

Is this issue correlated with a lot of radio activity? The SoftDevice will interrupt the application whenever there is any radio activity, which will explain the timing variations you're seeing.