ICG Variance - MC9S08AW16

[plaiming]

I am using the MC9S08AW16 as a motor control supervisor and speed control. I am using Codewarrior 5.9 and processor expert for initialization and using the ICG as main clock.  I  monitor motor speed by monitoring a hall effect sensor in the motor.  When the hall effect sensor triggers, I start a timer and measure time until the next hall event.  This has worked pretty well for the first few boards, but the latest board is significantly off in measurement.

Attached is my code to measure the time:

void getperiod(void){
  TPM2MOD = 0xffff;
  KBI1PE_KBIPE0 = 1; // enable keyboard enable bit 0
  KBI1SC_KBACK = 1; // clear interrupt
  while(!KBI1SC_KBF); // wait for keyboard interrupt
  KBI1SC_KBACK = 1; // clear interrupt
  TPM2CNT = 0;  // zero the timer
  while(!KBI1SC_KBF); // wait for keyboard interrupt
  KBI1SC_KBACK = 1; // clear interrupt
  HallPeriod = TPM2CNT; // total period
}

Could this be due to variance in the ICG? What is the best way to check this?

-paul

Added p/n to subject.

Message Edited by NLFSJ on 2008-09-16 03:42 PM

[peg]

Hello Paul,

Hmmm, Why aren't you using the input capture on the timer for this?
You are using KBI but then polling for the flag???
You are then manually resetting and capturing the counter value after further polling.
This is what the input capture mode of the timer is specifically designed for why are you doing it so inefficiently?

[plaiming]

>Hmmm, Why aren't you using the input capture on the timer for this?
>You are using KBI but then polling for the flag???
>You are then manually resetting and capturing the counter value after further polling.
>This is what the input capture mode of the timer is specifically designed for why are you doing it so >inefficiently?

Honestly, I dont know about the input caputre mode of the timer...
This may not be the most efficient way to set it up but I dont know why it wouldnt be consistent enough for what im doing..Wait for the flag, clear it, start the timer, wait for the flag again, read the timer...

Ill look into the mode you mention. I still think there is something quite different which is giving
me a consistently different timer value on one particular chip.

[peg]

Hi Paul,

What you have should be pretty accurate as long as there are no interrupts occurring to introduce random delays. Also it is OK if you are prepared to block while waiting for the event to occur. However the input capture does all this for you in the background in hardware, immune from interrupts etc.

Also I see here I have the answer to my other question. Looks like this particular device has an untrimmed oscillator that is a little further out than the others. What are you using to connect to the device? It can probably calculate the required trim value for you.

[plaiming]

> What are you using to connect to the device? It can probably calculate the required trim value for you.

I have both a P&E multilink and cyclone pro is that is what you are referring to.

[bigmac]

Hello Paul,

In addition to the interrupt latency issue, as identified by Peg, have you programmed the trim value, and does your code then read that value, within flash, and set the ICGTRM register?  If this is not done, the ICG internal reference frequency could be +/-25 percent from nominal value.

Is it possible that the calibration and programming of the trim value was inadvertently omitted for the later boards?  To detect whether this omission may have occurred during production, it is wise to provide a "sanity check" within your initialisation code, to test if the flash byte still contains the unprogrammed value of 0xFF.

Regards,

Mac

[plaiming]

>In addition to the interrupt latency issue, as identified by Peg, have you programmed the trim value, and does
>your code then read that value, within flash, and set the ICGTRM register?  If this is not done, the ICG
>internal reference frequency could be +/-25 percent from nominal value.


Unless this is done with the normal default processor expert initialization sequence, no, I am not programming or verifying the trim value.

Message Edited by plaiming on 2008-09-17 06:14 AM

[peg]

Hi Paul,

Is this inaccurate board always the same value or is it giving a varying value over time? If it is consistent but different from another then the issue is very likely one of an untrimmed internal clock. It holds its frequency quite well but can be a fair bit out "out of the box"

[plaiming]

Yes, the measurement was as consistent as the other boards. The time measurement was the
same but the ACTUAL time seemed to be different.

I am not using any interrupts in my application - so i am simply calling the function when
I want to sample the speed, and blocking until i get a result. This is acceptable for now.

Why are the oscillators not trimmed during manufacturing test? What do I need to
do to trim the oscillator properly?

[peg]

Hello Paul,

A factory calculated trim value is programmed into a reserved flash location at $FFBE. It is up to the user code to move this value into the active RAM based register at $4E where it will be used to trim the ICG.
When you mass erase the device you will destroy this value. Due to other factors like temperature and operating voltage you should calculate this value yourself in circuit. Code warrior has an option under the Multilink/Cyclone Pro menu for the BDM adapter to calculate this value and programme it into the non-volatile location used by the factory. It is still up to the user code to sanity check the value and then move it to the working register ($4E). So during development, usually you erase and re-calculate/re programme this trim value on every test cycle.

[plaiming]

Peg,

Thanks for the information. I am still a little confused what I need to do for production. In production, we are using a cyclone pro to program the chips in circuit. We are getting some percentage of units where the ICG appears to be off enough to cause our control functionality to be out of spec.  These units were never used for development so I dont think they would have been mass erased unless that is what the cyclone pro does before programming.

I do not see an option in the cyclone pro image manager utility to compute and program the $FFBE location with ICGTRM value.  What do you recommed we do.


-paul

[peg]

Hi Paul,

I have never used a Cyclone Pro etc so I am not familiar with them.
It is quite usual to have a programming script do a mass erase first, just so it works every time, already programmed or not. You have not confirmed here that you have your code moving the trim value to the working register. As for the ones already programmed, connect with the debugger and check what is happening. If there is $80 in $4E in more than a couple then you are not trimming properly.

I am sure you can set up a Cyclone to calculate and programme trim when it is operating standalone, you just need to work out how to set it up. Or maybe someone else familiar with these might help out here.
Simply programme these again ensuring the trimming is done correctly to fix them.

[JimDon]

I recommend that you submit a service request to P&E asking them the proper way to do this.