Attaching RTTviewer significantly changes interrupt characteristics

RE: Attaching RTTviewer significantly changes interrupt characteristics

Sigurd Hellesvik — Thu, 18 Apr 2024 12:02:35 GMT

Hear thy, hear thy: the thoughts have arrived:

Firstly, some times running things from interrupts can be a poor idea in zephyr. Maybe start the timer from something else than interrupt context?

Secondly, you already have a timer running, no? Instead of starting a new timer for your timeout, you can create a new CC value with its own interrupt and then use that one for your timeout.

If you want to discuss this further I suggest that you start a new ticket, so we do not clog this one.

RE: Attaching RTTviewer significantly changes interrupt characteristics

Sigurd Hellesvik — Mon, 15 Apr 2024 07:56:27 GMT

Good to hear that the new method solves the RTT problem!

And thanks for the summary, always helps a ton of other customers or people from support find the same issue later. For that reason I will mark your previous comment as "Verified Answer", so people find it easier.

For the rest of your thoughts: I have a colleague who I think might have some insight into this, but he is busy the next couple of days. After that, I will ask him to read over and return here with what we think.

RE: Attaching RTTviewer significantly changes interrupt characteristics

Nathan45 — Fri, 12 Apr 2024 19:53:33 GMT

What I mean by not seeing any improvement is this:

Run a test by writing a stripped down program that only contains a zephyr API gpio callback that captures time differentials and record those in an array.

Tun another test by writing a stripped down program that only contains a program which uses PPI to capture the clock and uses either the zephyr gpio interrupts or EGU interrupts to record the differentials to an array.

If you compare the two array's standard deviation and means they are not very different. HOWEVER. When I looked at the data in excel It turns out it makes more of a difference than I initially thought. For example, here is a capture of the data that I received. On the top is the old way (Zephyr APIs) and the bottom is the new way (GPIOTE+PPI+CLOCK+EGU). Significantly less noise. MOST IMPORTANTLY! I can confirm that this method is NOT affected by RTT!

I'm not sure if I'm out of the woods yet for this project but for now I think the RTT issue is bypassed at least.

Was there ever an answer on why RTT was causing a problem to begin with? I had an idea. In my original Zephyr API callback that contained my FSK algorithm, I was starting a k_timer over and over so I could tell when the whole thing was over. The reasoning was that so long as I kept kicking the timer it wouldn't expire so once the data stopped coming in the timer would expire and signal that data had stopped coming in. However, I noticed that even after I got the new way working, adding this k_timer_start() function into the new EGU callback was enough to ruin the algorithm. Let me put it this way:

Old way + k_timer_start() + RTT-connected = works

Old way + k_timer_start() = doesn't work

New way + k_timer_start() + RTT-connected = works very poorly

New way + k_timer_start() = works but not well

New way = works

Could RTT and k_timer APIs have an interaction? Just a thought.

Thanks for your help, I think this issue can be closed.

RE: Attaching RTTviewer significantly changes interrupt characteristics

Sigurd Hellesvik — Thu, 11 Apr 2024 08:16:59 GMT

[quote user="Nathan45"]I'm not seeing a significant improvement between using the PPI to trigger the capture task of the clock vs doing all of that within the interrupt just testing them head to head. I'm going to try my use case again using PPI to see if it works better than before with and without RTT connected.[/quote]

Oh well, I guess the main reason to put this on PPI is to avoid issues with timing when you introduce BLE later.

That being said, let us figure out what does not work here.

Could you specify in what regard you do not see any improvement?
It would be interesting to see if RTT has any effect on the PPI here as well, so I am looking forward to those results.

RE: Attaching RTTviewer significantly changes interrupt characteristics

Nathan45 — Wed, 10 Apr 2024 21:34:41 GMT

For anyone wondering how to make GPIOTE NRFX drivers play nicely with Zephyr GPIO APIs, this post should help

devzone.nordicsemi.com/.../ncs-v2-6-0-instructions-to-use-gpiote-and-zephyr-gpio-api

RE: Attaching RTTviewer significantly changes interrupt characteristics

Nathan45 — Wed, 10 Apr 2024 20:27:39 GMT

Yes!

After taking your advice and messing around for a while I finally understand. I plan on making another post that just explains how to use GPIOTE/PPI etc harmoniously with Zephyr GPIO APIs and even Interrupts.

It seems like the standard response to "how do I use GPIOTE while also using Zephyr GPIO APIs?" is something like "Nordic NRFX drivers for GPIOTE are not meant to be used in addition to Zephyr GPIO, it should be one or the other." I think that since NCS v2.4.99, the truth of the matter is that they CAN be used together, but you shouldn't initialize NRFX GPIOTE the same way that you would if you were only using NRFX (don't initialize NRFX GPIOTE inputs after initialize Zephyr GPIO interrupt). Like I said before, I will make a separate post with example program for NCS v2.6.0 and link to it here once it is up. I tried fiddling with sense-edge-mask in the device tree and even set it to 0x00000000 and then 0xFFFFFFFF and it worked both ways, so I'm not sure I was doing that right or not or if it makes a difference.

That said, back to my problem:

I'm not seeing a significant improvement between using the PPI to trigger the capture task of the clock vs doing all of that within the interrupt just testing them head to head. I'm going to try my use case again using PPI to see if it works better than before with and without RTT connected.

RE: Attaching RTTviewer significantly changes interrupt characteristics

Sigurd Hellesvik — Tue, 09 Apr 2024 13:11:46 GMT

After looking a bit aroud I have found the following:

When you set up GPIO with interrupts with the Zephyr GPIO API, it will use GPIOTE for the interrupts.

Note: Remember to set sense-edge-mask to 0. If this is 1, GPIOs get the PORT event enabled. However, to use PPI you need the IN event instead. This will consume ca 17.37uA more power.

Then you should be able to use nrfx_gpiote_channel_get() to get the channel and use nrfx for PPI.

Does this make sense?

RE: Attaching RTTviewer significantly changes interrupt characteristics

Nathan45 — Fri, 05 Apr 2024 18:22:00 GMT

When you say "set up GPIOTE with zephyr", do you mean use the APIs found here?

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfx/drivers/gpiote/driver.html#c.nrfx_gpiote_channel_get

I don't see any other GPIOTE APIs in the Zephyr docs.

RE: Attaching RTTviewer significantly changes interrupt characteristics

Sigurd Hellesvik — Fri, 05 Apr 2024 07:33:06 GMT

After talking some more, my collegua has an idea for using Zephyr GPIOTE and PPI together.

If you set up GPIOTE with zephyr, you can use nrfx_gpiote_channel_get() to get the channel for the pins you need, and then set up PPI with NRFX drivers.
This way, Zephyr has full control over GPIOTE, and it should be able to cooperate with itself to make multiple callbacks on those pins

RE: Attaching RTTviewer significantly changes interrupt characteristics

Sigurd Hellesvik — Fri, 05 Apr 2024 07:07:12 GMT

[quote user="Nathan45"]I do have a question I hope you can answer. I keep seeing conflicting information on the forums on how to use GPIOTE to trigger a peripheral task while also using the same GPIO to trigger a callback. I'm not sure how to do this? Can I use the normal Zephyr GPIO callback methods at the same time that I'm using GPIOTE stuff?[/quote]

I must admit that I have not tried this myself before, so I do not know.
I asked one of my colleagues who is more experienced than me on this and thay say that they are not sure how easy this will be to combine. So its a "maybe works"

However, if we take a step back and try to look at this from a bit more high level:

Zephyr does not have drivers to support PPI, so you will have to use nrfx drivers for PPI and gpiote by directly calling nrfx_ functions.
Zephyr as an operating system generally assumes that it has control over components, so in general cases I would say that you should be careful by mixing Zephyr and nrfx drivers for the same pins or peripherals.
And since you already are using nrfx_ drivers for some things, maybe it is not that bad to use nrf_x drivers for GPIO callbacks on the relevant pins?

Did I answer your question?

RE: Attaching RTTviewer significantly changes interrupt characteristics

Nathan45 — Thu, 04 Apr 2024 16:44:50 GMT

Thanks for the help so far! I'll start looking into PPI.

I do have a question I hope you can answer. I keep seeing conflicting information on the forums on how to use GPIOTE to trigger a peripheral task while also using the same GPIO to trigger a callback. I'm not sure how to do this? Can I use the normal Zephyr GPIO callback methods at the same time that I'm using GPIOTE stuff?

Nathan

RE: Attaching RTTviewer significantly changes interrupt characteristics

Sigurd Hellesvik — Thu, 04 Apr 2024 11:36:23 GMT

[quote user="Nathan45"]We are using BLE in prod[/quote]

In this case, BLE interrupts will likely mess up your timings as well.
Because of this, I would recommend using GPIOTE->PPI as you explain. I have been told that you do not need to use fork and EGU to handle the callback, so it should be a bit more straight forward.
The possible catch is that with 16kHz sampling, you might get some issues handling all the callbacks fast enough.

Does this make sense to you?

We are a bit swamped after easter, so I'm not digging very far into this yet, and I hope that you are able to test some with PPI yourself. But let me know if you got any more questions!

RE: Attaching RTTviewer significantly changes interrupt characteristics

Nathan45 — Wed, 03 Apr 2024 16:53:53 GMT

1. The delay could be as low as 16kHz, but I've been designing for worst case 20kHz

2. We are using BLE in prod, as well as NFC, UARTE, I2C, GPIO libraries. However, in the test program that I made the histograms with, I didn't use anything but the bare minimum, so nothing but GPIO.

I considered using GPIOTE+PPI+TIMER but I have one question.. I need to have a callback function to process the delay data as it comes in. Would something like this work?

GPIOTE->PPI------------>capture 16MHz timer

|----fork----->EGU-->callback function

RE: Attaching RTTviewer significantly changes interrupt characteristics

Sigurd Hellesvik — Wed, 03 Apr 2024 07:36:24 GMT

I did some more digging and I have some ideas here. The answer will likely be that you use PPI and a timer to measure this instead of the CPU.

But first two questions:
What is the lowest delay between two GPIO signals that you can get?
Will you use BLE at the same time?

RE: Attaching RTTviewer significantly changes interrupt characteristics

Nathan45 — Tue, 02 Apr 2024 17:45:18 GMT

Not sure if the video I posted went through. Here are some screenshots.

1. main() with HFCLK code added

2. Terminal output without RTTviewer attached

3. Terminal output with RTTviewer attached (same session, no MCU restart)

RE: Attaching RTTviewer significantly changes interrupt characteristics

Nathan45 — Tue, 02 Apr 2024 17:39:18 GMT

Thanks, Sigurd.

I gave your suggestion a try, and set the registers for turning on the HFCLK at the beginning of my program. The below recording shows how I placed the register settings at the top of my program, wait for the register to be set, then test it with/without RTTviewer connected.

I think this was a good idea.. maybe the HFCLK was getting unset even though I set it? I'll keep playing with it.

Do you have any other ideas? This is a showstopper for us.

Thanks!

devzone.nordicsemi.com/.../Screen-Recording-2024_2D00_04_2D00_02-at-10.33.26_2F20_AM.mov

RE: Attaching RTTviewer significantly changes interrupt characteristics

Sigurd Hellesvik — Tue, 02 Apr 2024 12:37:34 GMT

Debugging and RTT forces HFCLK to be set.
See SPIS: last byte missing if JTAG RTT disabled, otherwise ok

Could this be the cause of your problem?

Regards,
Sigurd Hellesvik

RE: Attaching RTTviewer significantly changes interrupt characteristics

Nathan45 — Fri, 29 Mar 2024 16:29:03 GMT

Just to add some more explanation to the histograms above:

I'm expecting two distinct frequencies (and therefore, periods) from my digital FSK signal. So by measuring the time_diff I'm able to measure the period between oscillations and decide which frequency it belongs to. If I take many time_diff (period) readings and plot them on a histogram, I should see two very distinct periods begin to emerge. The more clear these two periods are the better, as the algorithm would be able to place each time_diff reading in the correct category easier. I get a really good histogram when I attach the RTTviewer, as shown in the second histogram. However, in the first histogram the periods are more scattered about and less consistent. This leads to inconsistent behavior of the algorithm, especially down the line when it uses the demodulated FSK data to make more decisions.

This could probably be handled in software by just fiddling with the quantization parameters. However, there are more problems still down the line when it comes to the timing of flipping between the two frequencies that I don't know would be fixed.

RE: Attaching RTTviewer significantly changes interrupt characteristics

Nathan45 — Thu, 28 Mar 2024 20:15:11 GMT

This ticket somewhat reminds me of the issue I'm having, insofar as the application only works as expected with RTT connected. I can do something very similar to the video in this ticket with my application (but not with the mouse/ble. Just print statements doing/not doing expected results)

BLE stumbles without RTT Viewer.

Nathan