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

[seajayshore]

You may well be right... My ADC (I2C device) code currently has no error checking on some read/write operations and is called most frequently of all the devices.

I noticed on my scope that it seems various interrupts can cause timing variations on the I2C comms lines and, whilst most of the time this is benign between-packet delays (which I2C can presumably handle), it may well get interrupted at exactly the wrong moment and cause something strange to happen... Perhaps even causing the ADC itself to go into some weird error mode...

I'm exploring. Thanks for the help. Please let me know if the above theory sounds strange to you... I'll explore what happens after a fix in any case.

(BTW I've asked on mBed but it's a bit sparsely populated since the mbedOS split and I'm not getting many responses).

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

[seajayshore]

There is quite a lot of radio usage in the app. Some data is sent every ~30ms (minimum normal connection interval for iOS). But I think I'm preventing the ADC from being read at a moment where radio transfer could occur. (I'm using a radio-notification callback to set a flag that dictates if the ADC and other things can be polled). Still strange delays can occur in the I2C transfer, possibly now due to a ticker/RTC1 interrupt happening quite rapidly. Can you tell me, it's definitely not a good idea to disable interrupts briefly on this nRF51822 M0 right? You can only disable ALL interrupts on an M0 I believe, so this would cause the Softdevice to fail too...?

[bjorn-spockeli]

I apologize for not replying sooner. Yes, disabling all interrupts will cause the SoftDevice to assert. You can use sd_nvic_critical_region_enter to disable interrupts going to the application, but interrupts will still be forwared to the SoftDevice.