ICS FLL and DCO details?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

ICS FLL and DCO details?

Jump to solution
1,001 Views
Obetz
Contributor III

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

Labels (1)
0 Kudos
1 Solution
296 Views
Obetz
Contributor III

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

View solution in original post

0 Kudos
1 Reply
297 Views
Obetz
Contributor III

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

0 Kudos