Timer not stopping through PPI

RE: Timer not stopping through PPI

Håkon Alseth — Tue, 27 Apr 2021 10:48:41 GMT

Hi Ted,

[quote user="Ted Jones"]

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.

[/quote]

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

RE: Timer not stopping through PPI

Ted Jones — Mon, 26 Apr 2021 13:28:51 GMT

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.

Thanks,

Ted.

RE: Timer not stopping through PPI

Håkon Alseth — Mon, 26 Apr 2021 13:12:26 GMT

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

RE: Timer not stopping through PPI

hmolesworth — Fri, 23 Apr 2021 22:33:55 GMT

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.