NRF51822 Timer Stops Automatically with Softdevice

[Li]

Dear All,

We are working on a custom board with NRF51822.Everything works fine apart from the timer. What we are doing is that once the board is booted, it reads some values from an external ADC (240hz sampling rate) and write those values to an external flash device (every 30 seconds). We use timer to control this (timer is supposed to wake up every 3ms). All these run on top of softdevice (s110,7.0.0) as we need to connect to the board occasionally to read those values out.

The problem that we have now is the boards are working fine for the first 15 mins without any issue (ble can connect, data read and write to flash, flash can be read too). However, after certain period of time (more likely to be 15 mins or so), the boards halt completely (no action at all and cannot be connected). When this happens, we'll have to manually power restart the board and everything resumes working fine for another 15 mins.

We are suspecting that the board goes to deep sleep mode on its own for some reasons. we have sd_app_evt_wait in our main while loop. but this should just put the board in low power mode. As long as there is a interrupt from ADC or flash writing, the board should be woke up? Or why it works fine for 15 mins only?

We've searched around the zone but don't seem to find a discussion on this? Any help on this would be deeply appreciated!

[Stefan Birnir Sverrisson]

Hi Li

Make sure you do not use TIMER0 and RTC0 when the softdevice is enabled, as the softdevice uses those peripherals. But I doubt that is the case since the communication is fine for 15 minutes.

What sd_app_evt_wait does is mainly to disable the CPU. This is normally done so that power can be saved between BLE radio events when the CPU is not needed. Read more about that in the current consumption guide. All other peripherals can be enabled. So if you are communicating with e.g. the SPI master to the external modules, then SPI master should be fully operational in System On low power mode after you have called the sd_app_evt_wait. When a byte is received on the SPI, there will be an interrupt indicating that SPI data is ready and the CPU must wake up in order to process the data.

How are you communicating with the external flash? Can you describe a little better your method of communication with the external ADC and flash? What is the priority of the interrupts that the external ADC and flash trigger?

3ms is a short time. BLE connection event transferring one packet takes ~1ms, transferring 6 packets takes ~6ms, so I perhaps suspect that this sampling frequency is perhaps too high. Do you see the same behavior if you decrease the sampling frequency to e.g. every 10ms? How long does it take to sample?

Since you sample 240 times per second and only transfer data to flash every 30 seconds, I suspect you need to store a lot of sampling data at once. Does that work when you have to send data over BLE at the same time?

[Li]

Hi,

Thanks Stefan. We figured out the problem was not related to the timer but some memory leaks in our problem. It keeps consuming the memory and this answers why it stops around the same time. After we fixed it, everything works just fine now.

[Stefan Birnir Sverrisson]

Ok, thanks for your feedback. I am glad it works for you now!