timing information

[JayPRab]

Hi,

• I am running Keil uVision V5.23.0.0, debugging a 51822 using the J-LINK / J-TRACE interface built into the chips
• My code uses SD110, SDK 7.2
• I need to get ABSOLUTE timing info on my product
• Ideally, something simple like a time-stamp from the PC at the start of a routine and another one when the routine ends would be GREAT!
• I have tried SEVERAL different things to get this info, including:
  • using a ULINK 2
    • It seems this is just the same as using the built-in J-LINK interface and doesn't provide any more info that the native debug interface
  • including a debugger init file that, when called from break points set at the proper addresses, prints the number of states
    • However, this always just prints out 0 states....
    • watching the variable "states" shows only a 0x00
  • using the "PA" command from the command window...
    • ALL accesses come back with 0 hits...
• I have looked through thousands of postings about how Trace could help but it seems as if it only works with an nRF52 device, not the nRF51 that I am using
  • AND it needs a ULINKpro to go with it

Can anyone please tell me how I can get this info from the Keil interface please?

Thanks!

[Sigurd]

Hi,

The easiest, and also maybe the best way to measure “ABSOLUTE timing” is to toggle a GPIO when you start the routine, and toggle it again when you exit the routine. You can then use a logic analyzer or scope to measure the timing.

[JayPRab]

Thanks, Sigurd,

Ya. Did that. Perhaps a bit of background on what I'm trying to do. A bit of a long read, so I apologize in advance.

• My nRF51 code needs to keep the amount of accumulated time-error down as much as possible
  • Hence the need for "absolute time"
• My code uses the SD110-based RTC0 tick timer, set for 1mSec interrupts
  • Every interrupt, I need to update a display to prevent blinking
  • I already know that the 1mSec is in reality 1.007 mSec long (32.768KHz clock), so that's an easy one to correct for
• However, what I've seen is that when BLE events happen, the RTC0 Tick can go away for as long as 4 mSec...
  • It seems to happen when the nRF does it's thing to keep the BLE connection alive
  • I determined this by twiddling a GPIO pin in the Tick Timer ISR and using my logic analyzer set up to capture events LONGER than 1.007 mSec apart
  • However, the regularity of this is difficult to determine, to see how the error accumulates over time and whether I can brute-force some sort of correction every 's' Secs or so
• So, what I would like is to see independent time stamps from something OUTSIDE the development system (my board, the Keil IDE, etc.)
  • This would be the PC
  • I could run the code for an hour or two and log the time stamps and determine the rate of error accumulation and correct for it
  • I tried using the time stamps on the nRF Toolbox UART app (which receives messages from my nRF along with time-stamps generated by the nRF) but the problem here is that there is unknown and non-repeatable latency in when the message actually is received by the app on the phone...
• I have even gone further in this investigation by using a 1MHz crystal oscillator as an input to a GPIO pin.
  • This pin is set up as a GPIOTE event
  • Timer2 set up as a counter with the GPIOTE as an input, via PPI
  • I count the number of oscillator pulses when the 1 mSec interrupt happens
  • Again, I can confirm that this DOES show larger than normal oscillator pulse counts every so often

On the other hand, you could also tell me why the SD is taking away my Timer Ticks when it gets busy with BLE stuff? The docs seem to indicate that this should NOT happen....

But, at the very least, I'd like to know how to get time-stamps from the PC which is running my Keil IDE into the debug environment...

Thanks!

[Sigurd]

Hi,

JayPRab said:

My code uses the SD110-based RTC0 tick timer, set for 1mSec interrupts

RTC0 is used by the SoftDevice. From the S110 SoftDevice Specification , page 32-33, you can see that RTC0 is blocked when the SoftDevice is enabled. You should try to use RTC1 instead.

[JayPRab]

Sigurd....

I wrote ALL that detailed stuff and you come back with this...

Never mind

Thanks

[Sigurd]

Hi,

The first step would be to switch to RTC1.

You could then to send the RTC-tick measurements over to the PC using Segger RTT or UART. What is the main-goal of the timestamp ? Measure how long time different functions/routines takes? or to keep track of time in general ? If it is for general timekeeping in the application, then you should take look at the nrf-calendar-example that we have on GitHub.

[JayPRab]

Thanks, Sigurd.

Will look into this.