Hello all,
ist there any real "in depth" documentation of the S08ICSV2?
The information in AN3041 is not more than that from the data sheet.
I would like to learn more details about the DCO and the FLL to be able to predict worst case jitter for arbitrary time intervals.
The data sheet specifies jitter only for a 2ms interval, but I observe a random delay of exactly two bus cycles (125ns) even for very short intervals on one 9S08SH32, but not on another 9S08SH.
Thanks in advance,
Oliver
Solved! Go to Solution.
Correction: The 2 cycle jitter does not come from the DCO or FLL but from the BDC (background debug controller).
In contrast to the 9S12 BDM, the 9S08 BDC steals bus cycles when memory is accessed. I wasn't aware of this since the Data Sheet writes "non-intrusive commands for memory access" and "does not interfere with normal application resources"...
Well, I read that the BDC steals one cycle, not two, but this might be a(nother) documentation error.
And this event halts not only the CPU but also the TPM counter I used for jitter measurements! Well, that's not too bad since subtle errors could arise if code would be delayed but not the TPM counter. Imagine setting an OC event in the "nearest possible future".
So be careful when using realtime variable watch in extremly time critical applications.
I observe no more than 0.5% jitter for short periods (e.g. 10us).
Nevertheless it would be very interesting how the DCO works to get the worst case values.
Oliver
Correction: The 2 cycle jitter does not come from the DCO or FLL but from the BDC (background debug controller).
In contrast to the 9S12 BDM, the 9S08 BDC steals bus cycles when memory is accessed. I wasn't aware of this since the Data Sheet writes "non-intrusive commands for memory access" and "does not interfere with normal application resources"...
Well, I read that the BDC steals one cycle, not two, but this might be a(nother) documentation error.
And this event halts not only the CPU but also the TPM counter I used for jitter measurements! Well, that's not too bad since subtle errors could arise if code would be delayed but not the TPM counter. Imagine setting an OC event in the "nearest possible future".
So be careful when using realtime variable watch in extremly time critical applications.
I observe no more than 0.5% jitter for short periods (e.g. 10us).
Nevertheless it would be very interesting how the DCO works to get the worst case values.
Oliver