ICS trim reset during debug

[davidsherman]

I've got a peculiar problem.  We are using a KE06Z128VLH4 and KDS 3.0.0.  The KE06 is using the FEI clock at 48 MHz and we are using a P&E Multilink Universal FX.  For some reason, during debug in one environment the ICS_C3 register which trims the internal clock is being reset to 0x80.  The default values are typically 0x4f-0x5b for the factory trim value.  What is strange is that using the same debug configuration settings and the same board, one computer is debugging normally with the ICS using the factory default trim, but on another the trim is being reset to 0x80, which is throwing the clock off.  We can't find any option under the debug settings to control this, and we are using the same ARP file.  We even tried deleting the debug configuration and creating a new one.  The board boots normally out of ROM and runs at the correct speed, it's just under debug on one machine the ICS is somehow being changed.  Is there some option that we are not finding?  I see the ARP file sets the ICS trim value, but is there someplace else the debugger changes it?  I've confirmed that the 0x3FE and 0x3FF locations contain 0x4F and 0x00 respectively for the board.

[kerryzhou]

Hello David Sherman,

   What the project you are using? bare mental or the PE?

  In the P&E Multilink Universal, do you enable the trim function?

This is the KDS opensda configuration, it is the same as multlink:

You can try use this Trim again, then check the ICS_C3 and C4 register.

If you still have question, please let me know!

Have a great day,
Kerry

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

[davidsherman]

Thank you, we are using Processor Expert.  The checkbox to initialize the slow trim value is unchecked in both environments, although I found that checking the option to initialize the slow trim value makes no difference; Processor Expert still does not generate any code to initialize the slow trim value.  The option to program the trim value in the debugger options is unchecked, although checking that made no difference.  The debugger is somehow still programming 0x80 into the trim register, but only on one development computer.  I think we'll just have to work around it by writing our own code to read the trim value and program it.

[kerryzhou]

Hello Davide Sherman,

   I don't know whether you select the yes in the initialize slow trim value like my picture in the last reply:

Actually, after you select it, and generate the code, you will find there have the according code about it.

Then after you use the P&E tool, and configure the trim, the debugger will put the trim value in 0x3fe and 0x3ff, then when the code run to the above position.

It will copy the trim value to ICS_C3 and ICS_C4.

Wish it helps you!

If you still have question, you can share the smallest project which can reflect the problem to me.

Have a great day,
Kerry

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

[davidsherman]

Thank you, but apparently enabling the ability to initialize the slow trim value does not cause STARTUP_CLOCK_INTERNAL_SLOW_TRIM_ADDRESS to be defined in the version I have, so it never reached the code in CPU_Init to read from 0x3fe and 0x3ff to set ICS_C3 and ICS_C4.  I saved the PE configuration, re-generated the processor expert code, but it did not work.  Where does the KE06 read the default values from at reset?  Apparently it is not 0x3fe and 0x3ff. I moved the line from CPU_Init to actually run and set the clock, but it set ICS_C3 and ICS_C4 to 0xFF.  My chip would power up with 0x58 and 0x0 for ICS_C3 and ICS_C4_SCFTRIM and run at the correct clock speed, but it had 0xFF stored in 0x3fe and 0x3ff.  I used the debugger option to re-calculate and store the values in those locations.  They are programmed there now, but I'm curious where the chip gets the factory default trim values from at reset.

[kerryzhou]

Hello David,

  Please attach your project, I need to check it on my side, thank you!

Have a great day,
Kerry

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

[davidsherman]

Thank you Kerry, but what would help us considerably at this point is knowing how the P&E debugger should be setting the ICS trim values, since apparently it is not working properly in all cases when debugging.  According to the KE06 reference documentation, during reset it reads the trim values from a factory programmed location when not in debug.  Where is this factory programmed location?

[kerryzhou]

Hello David Sherman,

   The trim value have the specific algorithm, the P&e debugger tool will calculate it, then put it in the address 0X3FE and 0X3FF, then the code after startup will read these flash address, and put it in the ICS trim register. After reset, the trim value will use the factory trim data in default, if you trim it, the chip will use the new trim vault, otherwise, it will use the factory trimmed data.

  After the factory programmed location, it is not share with the customer, we also don't know it.

  So, if  you want to trim the chip, you can use the P&E debugger tool to realize it, or you can use the external crystal, then you don't need to use the trim function to get the other internal frequency which is different with the factory trimmed frequency.

Wish it helps you!

Have a great day,
Kerry

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

[davidsherman]

Hello Kerry, if you go back and read my other posts, the chip had 0xFF stored in 0x3FE and 0x3FF, yet the ICS powered up with correct trim value running under debug.  Where does the ICS get this factory reset trim value from?  Hint:  It's not 0x3FE and 0x3FF.  Please answer the question.

[kerryzhou · Accepted solution]

Hello David,

   1. Where does the ICS get this factory reset trim value from?

      It is from the chip internal some special address which is not shared with the customer, we also don't know it. Customer also don't need to know it.

   2. About the middle flash address 0X3FE, 0X3FF,

     This is just the middle trim address, it only can be used when you use the P&E debug tool, and enable the trim function both in the PE configuration and the P&E debug configuration.

About the configuration, I already have shared the picture with you before,check floor 2.

    Now, post some test result on my side.

  This picture is the result which I enable both the trim function in PE configuration and the P&E debug configuration.

  You can find the 0X3FE and 0X3FF already have the trim data.

  The above picture, which I did copy the data from the 0X3FE, an 0x3ff, you can find actually, because the default factory trim value is 37.5Khz, so even I enable the re-trim function with P&E tool, the trimmed data is the same as the default factory data.

   This picture is after read the data from address 0x3fe, 0x3ff.

I also attach my test project for your reference.

3.  Didn't enable the trim function, read ICS_C3 and ICS_C4 with different PC.

  configuration:

PC 1 test result:

PC2 test result:

You can find, the same project, the same board, different PC, I can get the same factory trim result without the re-trim function.

My debugger is the P&E opensda, my test board is the FRDM-KE06.

Another way you can test, you are not select the trim, then add the uart printf function, and printf the ICS_C3,C4 in the main.

Don't use the debug, just download the code, check the uart printf data on your side, doing this just to exclude the debug and debugger problem on your side.

Wish it helps you!

Have a great day,
Kerry

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

[davidsherman]

Thank you for your assistance, I appreciate it.  We were only trying to find out how to read the factory trim value, and it seems we can't.  Our automated production programming does not perform the trim operation since the factory trim has always been fine.  For unknown reasons one debugger is corrupting the ICS on multiple boards and throwing the timing way off, but the same boards power up fine running from flash without code to set the ICS C3 and C4 bits.  We were hoping to avoid having to make a debug-only configuration to overcome this problem and/or modifying the production programmer code to perform the trim operation.  We will manage though, thank you.

[kerryzhou]

Hello David,

   So, if you suspect your debugger, you can use my another way.  Use the uart to send out the ICS_C3 and C4 after you download the code to the chip, and with out debug mode.

Have a great day,
Kerry

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