This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Timer not stopping through PPI

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.

  • Maybe another Timer 1 compare Event 1 triggers again after a Timer 1 wrap-around; perhaps also try issuing a Stop and Clear  to timer 1 so that a wrap does not occur and Timer 1 then waits for a new interrupt transition of the trigger pin. This also assumes that the trigger pin does not issue repeated triggers; most interrupts on the nRF52 are level-sensitive not edge-sensitive, and if the trigger pin interrupt event is not cleared correctly in the handler it will re-trigger Timer 1 and hence Timer 2 for as long as the trigger pin stays high.

  • 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

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

  • 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

Related