Trim value could not be measured properly

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

Trim value could not be measured properly

Jump to solution
1,930 Views
bpaehr
Contributor IV

I am using CodeWarrior 10.6.4.  I was using an MC9S08QB8 device, but I needed a few extra pins to be able to also use my serial port for dumping data to a computer terminal, so I switched to an MC9S08SH8, which has 4 extra pins in a TSSOP package (pins 1-8 and 13-20 are same functions as previous device in the same location, and adding pin 9-12 extra functionality).

 

After starting a new project as an SH8, and copying all of my code to the new project folder, when I try to start the debugger, it gets to "Initialization" and pauses for awhile, then I get this error: "Error measuring trim values".  [OK]. "The trim value could not be measured properly".

 

How can I get around this?  I am using the internal oscillator, not an external oscillator, if that helps.  I am not (knowingly) doing anything to the trim values.

Labels (1)
1 Solution
1,487 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Hi,

please check the attached video for  the "Advanced Options".

Can this help you?


Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
8 Replies
1,487 Views
bpaehr
Contributor IV

I found the following in HELP about a checkbox that enables calculation of the Trim value and programming the Trim Register, but I can't figure out how to get to that particular Window/Dialog:

Help on Trim Checkbox.jpg

0 Kudos
1,488 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Hi,

please check the attached video for  the "Advanced Options".

Can this help you?


Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,487 Views
bpaehr
Contributor IV

Jennie:

Yes, that helped very well.  Thank you.  After following the path to get to that checkbox, I unchecked it, and then the Debugger started up, programmed my code into the processor, and I was able to run.

However....

I had been experimenting with writing data out of the serial port using the QB8 device.  Now, with the SH8 device in place, the communications seemed off.  After some testing, I found that I had to change my SCIBDL baud register from 0x1B to 0x35 to get good communications at 9600 baud.

Since the SCIBDL value was originally calculated based on the BUSCLK of the QB8 device, I tried loading a small Assembler program into the SH8 that allows me to toggle an output bit for 10 CPU cycles high/low to then derive the BUSCLK frequency to see if that frequency had changed from the QB8 device.  This small program had worked fine on the QB8 device.

On invoking the debugger with the SH8 device and this small BUSCLK test program, I again got the error where it couldn't read the Trim values, so I performed the same procedure from your video to un-check the "Calculate Trim and Program the Non-Volatile Trim Register" checkbox, but the debugger still would not start up, giving me the same "Error measuring trim values" error.

TWO questions:

1) What am I doing incorrectly?

2) Will this type of issue cause a problem down the line when these SH8 devices have to be programmed on our Production floor for our final product?

0 Kudos
1,487 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Hi,

please upload the  SH8 project here, and illustrate how to reproduce your problem step by step?

I will check the problem directly from my side.


Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,487 Views
bpaehr
Contributor IV

Even more confusing, Section 10.4.1.1 "FLL Engaged Internal (FEI)" Mode, the default mode of operation, seems to indicate that the ICSOUT clock is derived from the FLL clock (which I assume to be 31.25KHz), and with RDIV defaulting to "000", which divides the clock by "1", or still 31.25KHz, how do I get to 8MHz?  It also mentions that "the FLL loop will lock the frequency to 1024 times the reference frequency", but 1024 times 31250Hz is 32.00MHz.  Very Confusing!!

0 Kudos
1,487 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Hi,

with FEI mode, FLL output = 31.25k*1024=32MHz

BUSCLOCK= FLL output/BDIV/2= 32/2/2=8M, here BDIV is bus frequency divider

SCI baud rate = BUSCLOCK/SCIBD/16=8M/52/16=9615

(SCIBDL=0x34 which decimal number is 52)


Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------


Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

1,487 Views
bpaehr
Contributor IV

Jennie:

Thank you for clarifying the calculation.  I had seen the BDIV bit-setting and assumed that, since the default value of BDIV caused the frequency to be divided by two, that THAT was the "divide-by-two" to derive the BUSCLK from ICSOUT.  Did not realize that the "divide-by-two" was in addition to the division provided by BDIV.

The easiest way to determine my bus clocks for both the QB8 and SH8 devices was to run a special 10-cycle assembler program.  Having a BUSCLK derivation formula in one place in the MCU electrical specifications would be beneficial.

0 Kudos
1,487 Views
bpaehr
Contributor IV

Jennie:

My apologies.  I spent about a half-hour gathering screenshots and diagnostic information from the error that was being generated to send to you, only to realize that, when I was trying to ZIP my project, that I had not changed the derivative of that old project from the QB8 device to the SH8 device.  After creating a new Assembler project for an SH8 device and copying the code for main.c over to the new project, the debugger started up with no problem.

I was surprised, though, that the apparent internal BUSCLK changed between devices from about 4.198MHz for the QB8 device to 8.00MHz for the SH8 device, which in turn required me to change my SCIBDL register value from 0x1B to 0x34 (I was off by "1" in my last post) to re-establish good serial communications. 

Can you tell me where to find the specification in the data sheets for the nominal free-running internal oscillator BUSCLK value? Or some method of determining it from the register settings? I believe I am operating in "FEI" mode (the default mode). Table A-9 "Internal Clock Source (ICS) Characteristics" (MC9S08SH8 MCU Series Data Sheet, Rev 3) mentions nothing about a nominal 8.00MHz BUSCLK.  I am operating at about 3.2V power supply.  Not sure how 8.00MHz (or 4.198MHz for the QB8) is derived from the internal 32KHz reference oscillator due to default settings (a factor of 250 for the SH8).

0 Kudos