Attaching RTTviewer significantly changes interrupt characteristics

Question

Hello, 
 nRF52840 
 ncs-v2.5.0-rc2 
 
 I am using a GPIO interrupt to trigger a callback on every edge on a particular GPIO. I am then timing the difference in time between interrupts in order to make calculations, such as decoding FSK and Manchester data. I got this to work really well but I was using the RTTviewer as my terminal. As soon as I disconnect the RTT terminal my algorithm stops working. I have discovered that the FSK data that I am getting is very well defined when the RTTviewer is attached. That is, there are very distinct frequencies. When I disconnect RTT the frequencies are much less defined and it becomes impossible to recover data from them. 
 Any reason why attaching RTTviewer would change the behavior of the interrupt? Timer? execution speed? thread handling (not that I even have extra threads..)? 
 
 I have attached two histograms, showing time_diffs between interrupts with RTTviewer both attached and unattached. 
 (psuedo code snippet)

void gpio_cb()
{
 this_time = get_time()
 time_diff = this_time - last_time // time_diff used later to make calculations and decide which frequency the FSK is operating at. WORKS WHEN RTTviewer IS ATTACHED!
 last_time = this_time
 ...
 //other calculations are made
 //works GREAT when RTTviewer is attached
 ...
} 
 
 Histogram of "time_diff" values without RTTviewer 
 
 Histogram of "time_diff" values with RTTviewer (literally just clicked connect->select correct options and MCU->okay, without even restarting it)

Thanks, 
 
 Nathan

Nathan45 · Accepted Answer

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.

Attaching RTTviewer significantly changes interrupt characteristics

Top Replies

core_v2_widget.Hide()