RE: Timer event handler problem

Elia_pell — Wed, 30 Sep 2020 12:00:23 GMT

Ok, I manage to print the log on debug terminal and in fact now it's working as expected (the log are the same as you): so thank you! From now on, I will use NRF_LOG_INFO instead of printf.

Best regards,

Elia

RE: Timer event handler problem

Jørgen Holmefjord — Wed, 30 Sep 2020 10:36:15 GMT

Are you running the code on a nRF52840 DK? It is outputting the log on the Debug Terminal when I run it. Which version of Segger Embedded Studio are you using? I tested this on v4.50.

If not, try using Segger J-Link RTT Viewer directly.

RE: Timer event handler problem

Elia_pell — Wed, 30 Sep 2020 10:33:51 GMT

Dear Jorgen,

Unfortunately nothing is print on the Debug terminal: why??

Regards,

Elia

RE: Timer event handler problem

Jørgen Holmefjord — Wed, 30 Sep 2020 09:10:01 GMT

Hi Elia,

[quote user=""]1) Why isn't the timer stopped instantly? (but it needs two cycles)[/quote]

Since you are handling the stopping of the timer in the interrupt handler, the CPU requires some time to wakeup and call the interrupt handler when the interrupt is generated. Since you have configured the timer with only 8-bits width, it will overflow when the internal counter reaches 255. This will happen after ~8 ms, which means that the CPU should have plenty of time to handle the interrupt before this if nothing it blocking the handling of the interrupt. I tested your code on my DK, but I'm not able to reproduce any of the issues you are listing. This is the output from my run:

<info> app: ON: 322

<info> app: OFF: 1282

I'm not sure how you have implemented the printf statements, but could these slow down the application and cause this behavior?

[quote user=""]2) Why are the timestamps not correct? (I expected that OFF - ON = 960)[/quote]

As you can see above, I'm seeing a delta of exactly 960 in my run. Again, I believe that something must be slowing down your code, causing this.

I have attached my test-project. Can you have a run with this and see what values it is giving you? devzone.nordicsemi.com/.../4578.timer_5F00_cc.zip

It is possible to configure PPI to trigger the STOP and CAPTURE tasks in hardware when the events are generated. This would prevent you from relaying on constant interrupt latency for giving correct results.

Best regards,
Jørgen