How to resolve conflict when generating HF clock out

RE: How to resolve conflict when generating HF clock out

MartinBL — Wed, 13 Sep 2017 08:25:15 GMT

Do you mind posting your entire code relevant to this? I can't see where you are initiating a second timer for example. You can edit your initial question and just add a .c file. Also,

What SDK are you using?
Did you confirm this: "If I start the other timer first and then this one, it runs (although I believe the first one stops - I haven't confirmed that yet)."
The softdevice is not using any GPIOTE channels as you can see here.

RE: How to resolve conflict when generating HF clock out

Angelo — Mon, 11 Sep 2017 12:14:31 GMT

Hi, yes I have typical error checking in the code and it gives no errors - I just removed all that to make this snippet easier to read. But I since found out that the code above somehow interferes with the GPIOTE in an unexpected way. I had four GPIOTE channels being used (four interrupts generated from four hardware pins) and they were all working fine, but after running the above code, one of the interrupts doesn't work. If the above code doesn't run, all interrupts are generated as normal. I understand there are 8 channels, but I'm only using 4 that I know it. (I don't think the SoftDevice uses any right?)

RE: How to resolve conflict when generating HF clock out

MartinBL — Mon, 11 Sep 2017 07:55:25 GMT

Hi, Any progress? I see that you are not checking the return codes of any of the gpiote functions in tof_init(). Have you tried debugging like this to check if maybe the return codes can give us a clue? If you call [nrf_drv_gpiote_in_init()](http:// nrf_drv_gpiote_in_init) twice with the same pin number, for example, it will return an error and your code will probably not work.