Timer not stopping through PPI

[Ted Jones]

I am having a very strange problem with timers and the PPI channels.

I am trying to take a fixed number of ADC samples at 1 ms intervals starting at a fixed offset in time from the occurrence of an interrupt.  I set a PPI channel to start Timer 1 when the interrupt pin goes high.  There is a second PPI channel tying Timer 1 compare event 1 to the start task of Timer 2.

Timer 2 has a compare event at 1 ms with a PPI channel tied to the ADC start task and a short to clear the timer and thus reset.

This all works fine, and I get my samples.  The problem is that I am not able to stop Timer 2.  I tried using a PPI channel to another compare event on Timer 1 set to the end time for the samples and tying this to the Stop task for Timer 2, this is how I would like it to work.  I also tried using the ADC End event for this PPI channel.  I know I am getting the events, I have an interrupt handler with some debug messages to validate this but Timer 2 never stops.

Could the clear short on the Timer 2 event be preventing this timer from being stopped?  That doesn't make a lot of sense to me but I can't think of any other explanation.

If needed I could post some code but I would have to simplify it to show just this sequence of events.

Thanks,

Ted.

[Håkon Alseth]

Hi,

 

It sounds like you should set the NRF_TIMERx->SHORTS register:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/timer.html?cp=4_2_0_23_4_0#register.SHORTS

 

Here you can set a short from COMPARE[x] -> TASKS_STOP.

And depending on what you want to achieve, you can also clear the timer when this compare[x] occurs.

 

Kind regards,

Håkon

[Ted Jones]

Thanks for the quick response.

Yes, I did set the SHORTS register.  I will try resetting in the interrupt handler instead and see if that makes a difference.

I may also be being misled by what I am seeing.  I noticed that my main thread is becoming unresponsive after the sampling so there could be a bigger issue.  I have a J-Trace and have been trying to get Ozone to work hoping it will give me some insight into what is going on but I have had no luck.  When I run this application in Ozone I get a hard fault during initialization.  I believe that it may be due to the softdevice not being flashed properly by Ozone.

Is there a good tutorial/example of how to get Ozone working with the softdevice?  I know the SEGGER project is set up to flash the softdevice and bootloader but I don't see an easy way to get Ozone to do this.

Thanks,

Ted.

[Håkon Alseth]

Hi Ted,

 

Ted Jones said:

I may also be being misled by what I am seeing.  I noticed that my main thread is becoming unresponsive after the sampling so there could be a bigger issue.  I have a J-Trace and have been trying to get Ozone to work hoping it will give me some insight into what is going on but I have had no luck.  When I run this application in Ozone I get a hard fault during initialization.  I believe that it may be due to the softdevice not being flashed properly by Ozone.

Is there a good tutorial/example of how to get Ozone working with the softdevice?  I know the SEGGER project is set up to flash the softdevice and bootloader but I don't see an easy way to get Ozone to do this.

 Ozone will not load the softdevice, and ozone reads the .elf file offsets; which in this case will give you the wrong SP/RESET vector being read from ozone.

See their wiki for more detailed information on how to setup ozone with a program that starts with an address offset: https://wiki.segger.com/Debug_on_a_Target_with_Bootloader

  

Kind regards,

Håkon