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