Trim value calculation

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Trim value calculation

2,457 次查看
SZheng
Contributor I

Hi,

 

I am using MC9S08SG16. I already selected "Initilize Trim Value"in CodeWarrior device initialization. Now my questions are:

 

1, Since the trim value in 0xFFAF is 0x80 already set, how accurate can the frequency reach using this setting?

2, Do I ahve to recalculate trim value? if yes, how to?

 

Thanks,

标签 (1)
0 项奖励
回复
7 回复数

737 次查看
peg
Senior Contributor IV

Hello,

 

You should allow your programming adapter to calculate the trim value for you as it varies with temperature and  most importantly, with voltage. If your adapter does not have this facility (OSBDM) then you have to test the running frequency yourself. There are many Application notes that describe methods of doing this. e.g. AN2312, AN2496 & AN2498.

 

As for the accuracy, this can be found in the Electrical Characteristics appendix at the end of the datasheet under ICS Characteristics.

0 项奖励
回复

737 次查看
ThaManJD
Contributor III

I'd like to tag a question on to this question. I just realised that the PEmicro BDM Multilink must be setting the non volatile trim value during debugging but the production programmer requires this to be an explicit step in programming. I don't really like this as a second step. 

 

The project runs on a crystal so my assumption is that the internal ref. oscillator doesnt have to be very accurate. It just has to be running to get the PLL/FLL going ?

 

I'm going to try to set the non volatile trim setting from code before i try to get DCO lock for a crystal. But i probably dont have to do anythin with the trim value in that case right?

 

 i was playing around with code that initialised the trim value from a the NVICGTRM (0xFFBE) but the code so far does not set the NVICGTRM itself. 

I programmed using the production programmer and did not set the trim value into NVICGTRM. The result was that the FLL wouldn't lock. When i redo it and set the trim value into the high flash register with the production programmer it's ok. Maybe this means a value of $FF was being loaded into the trim register? is there anything wrong with that value? In any case, would the FLL care what speed the internal ref clock is running at?

 

Like i said i'm pretty sure when using a crystal as reference i should have to do anything with the trim but i was experimenting with it. thoughts?

 

0 项奖励
回复

737 次查看
bigmac
Specialist III

Hello,

 

After POR, the ICSTRM value will be 0x80, at the centre of the trim range.  The FLL should lock with this setting, and other POR default settings will ensure that the maximum bus frequency is not exceeded in the initial FEI mode.  It should therefore be unnecessary to do anything before switching to FEE mode using the external crystal reference.

 

If you transfer the NVICSTRM value to ICSTRM, and the flash location has not been programmed, it is quite possible that the FLL will not lock because you may run out of DCO range at the low frequency end, for some devices.

 

Keep in mind that, when you select FEE mode, there will be a significant delay for the crystal oscillator amplitude to stabilize, and for FLL lock to occur.  This may range from a few milliseconds for higher frequency crystals (in the MHz range), but may be many tens of milliseconds for low frequency watch crystals, especially if the HGO control bit is set for low power mode.

 

Regards,

Mac

0 项奖励
回复

737 次查看
ThaManJD
Contributor III

I told a lie. It was locking. But it was running at the wrong frequency. If the trim value was $FF would this be the expected behaviour.

 

Anyways i've done away with the initialization helper setting the trim value from NVICGTRM and all is well. Still curious about how the trim value affects the dco when setting up for external crystal.

 

I'll admit i'm reying heavily on the initialization helper in Ccodewarrior fo uC 6.2 which as far as i can see doesn't show the affect the trim value will have on frequency calculations.

 

The crystal value is 7.3728Mhz on a S08GT16A

 

Also, i'm familiar with the delay in waiting for lock. It's never been a problem before and on a second look at my issue it is not one now either.

 

Thanks again for your help

JD

 

 

0 项奖励
回复

737 次查看
peg
Senior Contributor IV

Hello,

 

Presumably you are switching straight to one of the external modes on initialisation and then leaving it there.

If this is the case then the frequency of the internal reference generator is irrelevant.

You will power up in SCM where it uses the open loop DCO output and then either the crystal oscillator direct or it via the FLL.

Also using the debugger does not automatically programme a new trim value to the device.

Whether you programme the recommended trim value to the NV register or not does not matter

Whether or not you transfer this value to the working trim register does not matter.

It will change the operating frequency of the internal oscillator but as it is not connected to anything it is irrelevant.

 

0 项奖励
回复

737 次查看
ThaManJD
Contributor III

I'll further admit that i'm looking at the settings of the project over my colleagues sholder.

 

I'm now alittle sceptical about what settings he actually had and what he was telling me he had.

 

The project is fine now that hes taken out any mention of trim settings for the ICG. He may  have had some other setting different as well that was confusing the situation that he changed without telling me. Thanks for you answers again.

0 项奖励
回复

737 次查看
bigmac
Specialist III

Hello,

 

Since you are actually using a 'GT16 device with an ICG module (rather than the 'SG18 device with an ICS module),  the situation after POR will be slightly different.

 

The initial state will be self clocked mode (SCM) where the internal reference plays no role whatsoever, and the DCO operates "open loop".  The DCO output frequency after POR will lie somewhere between 5.5 to 10.5 MHz, giving a bus frequency range of 2.75 to 5.25 MHz.  Hence the trim of the internal reference is irrelevant.

 

Using an external crystal, you may then select either FEE mode or FBE mode.  FBE mode would give a (maximum) bus frequency of 3.6864 MHz.  Higher bus frequencies can be achieved with FEE mode.  What is the "correct" bus frequency for your application?  It is unclear whether you are yet able to achieve the operation you require.

 

If you are programming in C, the copydown process for initialisation of global variables will occur during SCM.

 

Regards,

Mac

 

0 项奖励
回复