Part Number: CC2640
Hi Team,
I have a customer who is working with the CC2640 and are doing the following:
CPU cycles on the CC2640 are to be counted which are then compared with the expired RTC cycles (from the AON_RTC_SEC and AON_RTC_SUBSEC registers) in order to carry out corrections. In order not to be disturbed by the TI-RTOS and other peripheral / software modules, which would lead to a loss of accuracy / accuracy, this process takes place before any initialization in the main function (ICall, Task, BIOs, etc.). At this point, they have tried two approaches:
A while loop with counters and NOPs has been implemented, which contains a precisely defined length of ASM commands. Based on the number of cycles for each command taken from the Cortex-M3 Technical Manual by ARM, the theoretical duration could be determined. This was calculated with the help of the CPU frequency of 48MHz (with some tolerance) so as to spend exactly one second in the loop. However, it has now been shown that if the value from the RTC is read, there is an external deviation at the time in the loop, which leads to the fact that one day is essentially longer / shorter. In addition, it has been shown that each measurement "measures" a completely different deviation. This means that in one run, it is 2 seconds and the next 10 seconds per day (calculated based on a one-second measurement), which gives a very broad spread. This results in the conclusion that in the background (even with deactivated interrupts by "cpsid i") on the chip other things are still running, which were started before reaching main ().
After the unsatisfactory output of this first attempt, a second attempt has been made, whereby the loop with a defined execution length of a run is aborted when a 1 can be read from the register AON_RTC_SEC The number of passes is used with the time as a basis for calculation, results with similarly strong deviations and variance were obtained (deviation from reading / writing of RTC register is known), which should not be / should be expected in our expectation Hardware Breakpoint and then manually read via CCS IDE.
- The question now arises whether this type of approach can function at all from the point of view of TI (ie with a complete overview of the system), or whether too many uncontrollable variables are introduced (for example the Cortex M0, code already running, or other disturbing factors ...)?
- Another question is to initialize the RTC, which currently consists of an AONRTCDisable (), AONRTCReset (), and AONRTCEnable () because Clock_getTicks () does not exist at this point. Is this command sequence correct / sufficient?
- Additional question: The 48MHz system frequency synthesized from the 24MHz quartz is available from Power-On (according to the experience already when entering the BLE-Peripheral Main function) or where and when is the PLL initialized for this?
With no result achieved with the above concept, the idea was to shift the time measurement towards hardware, and to keep the implementation effort to a minimum. Thus, the SysTick timer was initially configured to generate an interrupt after 0.25 seconds (at 48MHz by 24bit depth limited to 0.34seconds), which was routed into a specially created function. In this function, the RTC is then read out and the values for further calculations or for debugging are buffered. This approach yields virtually the same results on each run and thus no longer shows the high scatter as before.
There is, however, a disadvantage: the times read from the RTC deviate so far from the set interrupt cycle that a deviation of several minutes (0.2247924805 seconds) occurs per day. In addition, these results do not coincide with observations made when our firmware with integrated calendar runs on the same hardware. This shows a daily time deviation of 10-20ppm. Furthermore, according to Bluetooth specification, which allows for the clock quartz a maximum deviation of 500ppm, the device could no longer communicate with other participants (BLE Peripheral firmware works however). At this point it is completely unclear to us where the measured differences come from.
Can you provide some insight here? What could be the cause of the discrepancy in the timings? Do you maybe have some ideas about how a deviation between the system clock and the crystal could be measured?
Thanks and Regards,
Mihir Gupta
FAE - South Germany
