Attaching RTTviewer significantly changes interrupt characteristics

[Nathan45]

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]

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

[Nathan45]

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.

[Sigurd Hellesvik]

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

[Nathan45]

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!

[Nathan45]

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)