MC9S08QD2 different timing in test and production

[marionmees]

Hello, 

I have a problem with my software timing. I've got a PCB with the MC9S08QD2. For developping the software for this I reprogrammed the device with P&E Cyclone Pro.

Now the PCBs are programmed for serial production by an external supplier and we found that the timing doesn't fit any more, the processor works  slower. 

I don't understand this behaviour because in the main the internal clock is initialized with 

ICSC1 = 0x07;

ICSC2 = 0xC0;

TPMSC = 0x4F;

TPMMOD = 0x0005;

Is there any possibility to overwrite this by programming? 

Is there any configuration I should keep in mind? 

Thanks for your help, 

Marion

[tonyp]

I believe you use the internal clock (based on you ICSC1 setup).

For accurate timing an accurate (and usually different) trim value needs to be programmed for each and every MCU.

Cyclone does this automatically but perhaps your programming service doesn't, or has a different assumption about what the operating frequency is.

[marionmees]

Thanks for your advice.

I requested the trim value of the production now.

Can you tell me how to set it in the Cyclone interface?

Mit freundlichem Gruß,

Marion Mees

[john_suchyta]

Hi Marion,

Tony is correct about the trim value that needs to be programmed on each MCU. NXP stores an 8-bit trim value for the ICS at location 0xFFAF in flash on our production line. The fine trim bit (FTRIM) is stored in bit 0 of the 0xFFAE. These locations are erased during a production programming process, so the programming tool must know to read them before erasing, and then program them after the application code is programmed. The Cyclone Pro defaults to calculating the trim value and then programming it after the app is programmed. This can be seen in the Advanced Programming Options in one of the Cyclone Pro windows. You can uncheck the Calculate Trim box, and the Cyclone Pro will copy the value that NXP programmed to re-program that value after the flash is erased and programmed with the app code. However, it is always best to calculate the trim value in the application because this is more accurate (accounts for the system parasitics).

A generic programmer that does not check for the trim values will erase all flash and only program the app code. Our trim value will be lost. (0xFF, the value of an erased location, will cause the ICS to run slower if this is used as the trim value.) There are production programmers that can read the NXP factory trim values, but this is usually an option that the program house or test engineer needs to enable.

Please make sure that your code reads the 0xFFAF location and stores the data to the ICSTRM register, and then reads the 0xFFAE location and stores bit 0 to the ICSSC register. Otherwise, the internal oscillator will use a default trim value of 0x80 which may not give you the frequency you desired.

Regards,

John Suchyta

[marionmees]

Hello John,

thanks for this detailed answer,

I hope I'll solve my issue with this!

Regards,

Marion

2018-09-13 18:38 GMT+02:00 jsuchyta <admin@community.nxp.com>:

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: MC9S08QD2 different timing in test and production

reply from John Suchyta

<https://community.nxp.com/people/jsuchyta?et=watches.email.thread> in *8-bit

Microcontrollers* - View the full discussion

<https://community.nxp.com/message/1057071?commentID=1057071&et=watches.email.thread#comment-1057071>