Is the internal reference clock accurate enough to use in the serial communication?

[sypii]

Hello, I'm a beginner of HCS08. In my design I have to use the serial communication, but there isn't a external reference clock or oscillator and my program runs in the FLL engaged internal(FEI) mode. In the document of the HCS08, it says we could get a good clock accuracy in this mode rather than a high clock accuracy. Usually the serial communication needs a higher accuracy of the clock, then I want to know whether I could use SCI in the FEI mode. If it is possible to use SCI in the FEI mode, what I should pay attention to?

Any suggestion or explanation will be greatly appreciated. Thank you!

Yang.

[celsoken]

Dear Yang,

If you are speaking of RS-232 communication, you'll need 5% error maximum between transmitter and receiver. If you are communicating with a PC or other xtal-controlled device, you should expect 200 ppm from the PC side so you could drift almost the 5% without problems.

Using BDM and codewarrior tools, you could trim automatically so you'll just have to check temperature and operating voltage drifts of your specific part. I've been using QG8 without any problem.

Cheers,

Celso

[mke_et]

Ok, with EXTERNAL serial communication like to a PC with a serial link, all you need is to be able to insure that at 10 bits, the 'cell' position is not off my more than 1/2 cell in the last data bit. Remember that serial communication 'resets' it's timing every byte, or 10 bits. There's the start bit, then 8 data bits, then a stop bit. Once the data bits start coming through, each 'bit transition' must be within the 'cell' time for that bit. Timing errors are cumulative per byte.

Someone said 5%. That's a pretty good figure, since it's 10 bits and 1/2 the cell of the last bit, but realize it's only to the MIDDLE of the 9th bit (the 8th data bit) that you have to maintain accuracy.

While 5% is fine for serial communications, it will really play havoc with A2D if you're using that on the chip!

[bigmac]

Hello,

The data sheet for the HC908QB8 actually provides the detailed calculations for baud rate tolerance (during receive) for its ESCI module.  For the SCI module within the 9S08QG8, I would expect the allowable tolerance to be similar, assuming a similar method of start bit detection for both devices.

The required tolerance on receive baud rate is somewhat tighter than the 5% currently assumed -

Incoming data slow : 4.5% for 8-bit data, 4.1% for 9-bit data.

Incoming data fast : 3.9% for 8-bit data, 3.5% for 9-bit data.

For the send baud rate, the allowable tolerance will depend on the operation of the UART within the remote device (PC etc.), and might differ slightly from the above figures.

For the 9S08QG8 device, the specified minimum period trim adjustment for the internal oscillator seems a little ambiguous with a typical value of 0.1%, but a maximum value of 0.2% (per step?).  This is the only means of fine adjustment of baud rate for the 'QG8.

For the HC908QB8, the internal oscillator adjustment is nominally 0.2 percent per step, but has an additional means of fine adjusment within the baud rate pre-scaler (one of the reasons it is called an ESCI).

The internal oscillator adjustment for the 'QG8 may need to take into account two factors -

1. The initial frequency tolerance of the internal oscillator (unit to unit variation), and
2. Fine adjustment requirements to compensate for baud rate errors associated with the baud rate divisor setting.

It is likely that the calibration process during BDM programming will take into account the first factor, but not the second.  However, since the second factor will be a fixed correction for a given baud rate, it should be possible to take the trim value determined during programming, and then add the additional correction.

Mike,

I am a little unclear on possible A2D problems - perhaps you might like to elaborate.

Regards,

Mac

Message Edited by bigmac on 2007-05-29 04:13 AM

[DustyStew]

Something to keep in mind when working out the RS232 tolerance to clock drift is the oversampling rate of the receiver. I am not referring to the HC08 here, I mean the chip on the other end of the line, whatever it happens to be.

The minimum oversampling rate that works is 3x the baud rate, though I think hardware UARTs typically use 16x. The ESCI uses 16x. 5% is presumably a theoretical best case, with 10bits x 5% = 50%, and that assumes the perfect receiver, which would be sampling the first bit smack dab in the middle (at the 50% point). Reality is, in the worst case scenario (3x oversampling), the first sample is somewhere between 1/3 and 2/3 of the way through the bit, because the incoming serial data is not synced to your clock, so you can have a one sample period delay until the start bit is recognized. With worst case 3x oversampling, you don't have 50% of forgiveness, you have 33%. It appears the actual number will be between 3.3% and 5% depending on oversampling rate.

Just to make things even more interesting, what happens when the receiver clock drifts one way, and the transmitter clock drifts the other? Seems to me we ought to be shooting for about 1/2 of the 3.3%..1.65%. Do yall concur? Or am I missing something?

Cheers
Dusty

[peg]

Hi,

Yes, all of this is quite correct and all the info is available in ther datasheets. Also don't forget this is worst case. If you are dealing with only ASCII you get the free re-sync bit. This means you will need more error to produce garbled chars first and very unlikely a framing error.

If you are comunicating with a PC or the like you can rely on this being very accurate and have the full +/-~4%. But if you have to allow for comms to unknown, possibly inaccurate other devices then you have to be tighter.

But back to the original topic, you can achieve <1% with the clock trimmed properly so most of this is purely academic.

[DustyStew]

Yes clearly this discussion has gone somewhat off-topic.

I was just looking at the MC908QC16 datasheet, and it's oscillator variance is typically +-2% over the 0-70 temperature range. On the QG8, +-2% is the max figure...apparently it is better characterized. If you want to split hairs, +-2% could be out of spec for RS232, that is, if you agree with 1.65% analysis.

Though I am just playing devil's advocate

[sypii]

Hello everyone,

Form your discussion I learnt a lot. Thank you again!

[Churro]

First sorry my bad english

It´s my solution for the trim´s value:

void main(void) {

  UINT8 mensaje[ ] = {' ','P','R','O','Y','E','C','T','O',' '};   // test string
  UINT8 tam = sizeof(mensaje)/sizeof(tam);               // large string
  UINT8 c = 0;                                                            // counter

  UINT8 flag = 0;                                                        // flag for increment or decrement trim

  OSCTRIM = Optional;                                             // trim value in 0x0000FFC0

  DDRB_DDRB5 = 1;                                                  // Tx pin output
  PTB_PTB5 = 1;                                                      //  Tx pin idle value '1'
    
  Init_CPU_QB8();                                                  // Configure config 1 and config 2
  esci_start();                                                           // Config ESCI module for communication at 1200 bps


  for ( ; ; ) {   
     enviar_byte(OSCTRIM);                                  // actual trim value

     DELAY(1000);                                                 // optional delay

     for ( c = 0 ; c < tam ; c++){                                         // send string using esci module
     enviar_byte(mensaje[c]);
     }

     DELAY(1000);                                                // optional delay

     if ( flag == 0 ) {                                                   // decrement or increment trim ?
       if (OSCTRIM>0) {                                        // if decrement and if trim > 0
         OSCTRIM--;
       }
       else {                                                         // else return default value and set increment trim
         OSCTRIM = Optional;
         flag = 1;
       }
     }
     else{                                                            // if increment and if trim < 255
       if (OSCTRIM<255) {
         OSCTRIM++;
       }
       else {
         OSCTRIM = Optional;                               // else return default value and set decrement trim
         flag = 0;
       }
     }
  }
}

In terminal program view the correct string and the TRIM VALUE

[peg]

Hi Churro,

I guess this method would be useful for a "real world" check.

However, you are relying on the recievers clock (pretty good on a PC), but more importantly the probably unknown valid bit detection method of it.

It may well have different tolerances acceptance of fast and slow data. So where is the middle?

Have you seen the following AN's on this?

AN2312

AN2496

AN2498

[DustyStew]

sypii

I am working with the HC908, not the 9S08, so perhaps this information will not apply...but here goes anyway.

I have had no problem using the internal oscillator for a baud rate of 9600, IF the oscillator is calibrated. If uncalibrated, it usually does not work. It seems like there is a range for OSCTRIM of perhaps +-5 steps or so. I can't remember exactly, but I have done this manually, using HyperTerminal to change OSCTRIM, and had it working, then it stopped working at which time obviously I could not change it back to make it work again! If I recall correctly there was a range of about 10 values where it worked.

First thing you can do is, before you program the chip,when it is fresh from the factory, there will be a trim value stored in FLASH. You have to grab that number before you first program the chip, then put it in your code, loading it into the OSCTRIM register first thing.

If you don't grab that number, or if for some other reason you want to calibrate the internal oscillator yourself, there is an app note that shows how to do this. I wrote my own algorithm, and I think it is more or less the same idea as the app note. You need a timing reference, which could be PWM from another chip with a crystal, or it could be the power line frequency, conditioned down to a 3V or 5V square wave. In your code, set up a timer to generate the exact same pulse rate as your reference input, assuming the internal oscillator was correctly calibrated. Then depending on which occurs first (ie rising edge of input pulse, or the occurence of your timer compare event), adjust the oscillator trim register up or down, in the direction that tends to make your pulse closer in frequency to the input pulse. The way it ought to go is something like this: down-down-down-down-up-down-up-down-up...etc. That is, because you can never perfectly tweek the oscillator, and due to the nature of the algorithm, it should naturally "hunt" between two values once you get to the desired value...one or the other. To work out which of those two values is closer is a little more difficult...but that should get you close enough to do the job.


Just to make things a little more interesting, it seems some of the chips have a bug in the oscillator trim circuit. I am working with the MC908QB8, so the oscillator is different than what you are using, but I discovered something very strange. It seems that the LSB of the oscillator trim is working in reverse. As if it was inverted. "Just to drive you nuts". I ended up ignoring the bit (making it zero always) and the above described algorithm worked well. I don't know if this is a bug in the particular batch I am using, or what.

By the way, a cheap way to calibrate the oscillator, without code, is to use an oscilloscope. Generate a pulse using a timer, measure it with the scope, and manually tweek the value loaded into OSCTRIM until the pulse is the width it ought to be for the desired clock frequency. You will need to reprogram the chip several times before you get it to the correct value. You can estimate how much to adjust the value by calculating the percentage change required, then dividing that by the % change per step (I think it's 0.2%...look in the oscillator spec sheet at back of the datasheet) This will get you fairly close, I expect close enough to make serial comm work.

Cheers
Dusty

[sypii]

Hi Dusty,

Your suggestions are absorbing, and I will try it.

Greatly appreciate your help! Thank you!

Yang.

[peg]

Hello Yang,

It is my experience that an S08 internal clock trimmed with P&E USB Multilink and P&E(CW) software provides a clock that is more than adequate for use as a baudrate source for the SCI module.

[tonyp]

The internal reference clock is good enough for serial communications (which allow for some baud rate mismatch) IF you actually get it tuned where you want it.  And when that happens, SCI works well.

The real problem for me is getting the MCU trimmed correctly.  My "undisclosed" tool doesn't do a very good job in that area, giving vastly different trim values on the same chip with every programming attempt, rendering the whole process useless.

So, to be safe I sometimes end up using a crystal just to solve this problem.

If your hardware has other means of user input (besides the SCI), you could also use your own trimming procedure to get the desired "center" frequency.

[sypii]

Hello tonyp and peg,

I really appreciated your help! But there's another question. To the same chip, do I need to trim the MCU again every time I have programed on it?

Thank you very much!

Yang.

[peg]

Hi Yang,

The trim value required depends on the chip, the applied voltage and the temperature.

If you are developing/debugging on one device and as these values are going to remain relatively constant then the answer is no.

However as the process is quick and automatic (if setup to be so) then it is usually best to re-do it every time. This also saves the head scratching when you do change to another device which WILL probably need a different trim value.

Message Edited by peg on 2007-05-27 11:32 AM

[sypii]

Hi Peg,

Thank you very much for your help!

I understand your words now, but could you explain briefly how to trim the internal clock automatically? There isn't a external reference clock always connected to the MCU, and I don't know what to reference when trimming the internal clock.

Yang.

Message Edited by sypii on 2007-05-27 05:28 AM

[peg]

Hi Yang,

By looking at your other threads here I think you are using the serial monitor to programme/debug.

I was referring to a method used when the communication method is by the BDM with a BDM adapter.

If you don't have a BDM adapter (such as P&E USB Multilink) then you may need to use a  method such as those presented in AN2496.

In this case you would just do it once and leave the value untouched as you go through the debugging phase.

HTH

[sypii]

Hello Peg,

Actually I could borrow a BDM adapter but it's very inconvenient, so I want to develop a serial monitor with the BDM adapter and then use the monitor to develop my own programs. I haven't ever develop a program on HCS08 MCU, and I felt it a little difficult. Especially I worried about whether the serial communication part could work properly with the internal clock. If it doesn't work, I will be in troubled.

Thank you again for your help! You are warmhearted

Yang.