nRF52832 Timer Enable Disable Fails Assert and Hard Faults

RE: nRF52832 Timer Enable Disable Fails Assert and Hard Faults

AmbystomaLabs — Mon, 02 Apr 2018 23:03:00 GMT

So to further explain it, you rely on a pin read to establish what you should do. Depending on the latency maybe that is true, maybe not. At any one time there should be only one IRQ tied to this function and one system event.

Likely things just get out of sync.

By moving all the start/stop to ppi. Your software event can focus on something always true which is to tally. You may have to figure out a way to keep the timer from proceeding until you tally. Just in case the pin is just getting hammered repeatedly without time for you to deal with it.

RE: nRF52832 Timer Enable Disable Fails Assert and Hard Faults

AmbystomaLabs — Mon, 02 Apr 2018 22:42:09 GMT

In addition to what I wrote above, this seemed relevant: https://devzone.nordicsemi.com/f/nordic-q-a/32566/gpiote-missing-event/125379#125379

RE: nRF52832 Timer Enable Disable Fails Assert and Hard Faults

AmbystomaLabs — Mon, 02 Apr 2018 22:41:05 GMT

It's not clear if you are using the gpiote driver or just registering system events with the SD.

Either way difficulties can arise. During normal operation the BLE stack will lock out the processor for anything related to your code. Just an advertisement can keep you locked out for nearly 1 msec. During this time ISR's can accumulate and perhaps the original state is there and perhaps not. There are only so many vectors on the NVIC and they need to play games keeping track of the events that need to be serviced.

Plus a msec here and there will give you a lot of random latency on your event timing.

You might be better off working it directly with the gpiote driver and using pin events. Since you said you need to do something on assert. It may be unavoidable to do everything in an ISR. However, looking at your code it seems that you just start the timer on assert and then when button is released (or something) you tally the events.

Better to let the PPI/GPIOTE handle the start/stop of the timer, then you can always use a soft event on timer completion for your process_hits. This way latency doesn't matter. You can put the timer clear either in the event handler or let the ppi do it via a fork or shorts.

RE: nRF52832 Timer Enable Disable Fails Assert and Hard Faults

edmcnicholas — Mon, 02 Apr 2018 22:33:03 GMT

This does not work if i need a GPIO to execute one event on high and one on low there seems to be a disconnect in the api for this type of behavior.

RE: nRF52832 Timer Enable Disable Fails Assert and Hard Faults

edmcnicholas — Mon, 02 Apr 2018 14:54:49 GMT

Thank you for the information and i will have to make sure i have channels left . I also need the GPIO event to trigger my processing function. Should i use PPI to control the clock and the interrupt to run the function? Also the gpio is driven by a time controlled circuit so the fastest it goes is 3.3mS.

RE: nRF52832 Timer Enable Disable Fails Assert and Hard Faults

AmbystomaLabs — Mon, 02 Apr 2018 14:38:41 GMT

You don't say what the min and max of the timer interval is. A common mistake is to exercise the timers in ISR's which are inherently delayed and sometime lost if you don't prepare properly for the event in code.

Since all you do is start and stop a timer based on gpio, you should have all that done in ppi/gpiote instead of pulling it out to an interrrupt. The ppi/gpiote can be configured such that a pin assert drives timer events.

Just remember the min timer time is 2 pclk's.

RE: nRF52832 Timer Enable Disable Fails Assert and Hard Faults

edmcnicholas — Mon, 02 Apr 2018 03:20:06 GMT

i am using sdk 14.2 btw