This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Oscillator calibration data memory location

Other Parts Discussed in Thread: CONTROLSUITE

I have used the code example mentioned in

http://www.ti.com/lit/sprab84

and I am using it on F2806x (even though example code is 2803x).

The locations for the following are different in my F28069:

  #define getOsc1FineTrimSlope() (*(int16 (*)(void))0x3D7E90)()
//Oscillator 1 fine trim at high temp
  #define getOsc1FineTrimOffset() (*(int16 (*)(void))0x3D7E93)()
//Oscillator 1 coarse trim
  #define getOsc1CoarseTrim() (*(int16 (*)(void))0x3D7E96)()

//Slope used to compensate oscillator 2 (fine trim steps / ADC code). Stored
//in fixed point Q15 format.
  #define getOsc2FineTrimSlope() (*(int16 (*)(void))0x3D7E99)()
//Oscillator 2 fine trim at high temp
  #define getOsc2FineTrimOffset() (*(int16 (*)(void))0x3D7E9C)()
//Oscillator 2 coarse trim
  #define getOsc2CoarseTrim() (*(int16 (*)(void))0x3D7E9F)()

//ADC reading of temperature sensor at reference temperature for compensation
  #define getRefTempOffset() (*(int16 (*)(void))0x3D7EA2)()

For example, I know in F28069 the Temp Offset is 3D7E82 and not 3D7EA2.  Where can I find all the correct locations for other things like Osc Fine Trim Slope and Osc Fine Trim Offset for my specific device?

My device is TMS.

  • Hi Fulano,

    All the F280xx_OscComp.c files should be accurate.  To move from device to device, you should be able to include the appropriate support files for that device and then re-compile without having to worry about exactly where the addresses are.  

    What makes you say the temp offset for F28069 is at 0x3D7E82 instead of 0x3D7EA2? Does the oscillator compensation function not work as expected?

  • Thanks Devin, I did not realize there was a F2806x example, I went by the examples listed in sprab84 which were only 2802x/2803x examples that I was trying to adapt to 2806x. Now I see that I can just use the osc_comp example from 2806x examples in controlSuite.

    The reason I thought the temperature offset address was different than the one in the osc_comp example (0x3D7EA2) is because in spruh18e (2806x tech ref manual), it says on page 521 that the slope is at 0x3D7E82 and offset is at 0x3D7E85.

    Now, I realize that 0x3D7E85 is 0degC temp sense offset, while 0x3D7EA2 is the temp sense offset at some other reference point which is why the address must be different.

    Another issue I see is, in the Example_2806xOscComp example, an OTP wait-state of 1 is used

    // Set the flash OTP wait-states to minimum. This is important
    // for the performance of the compensation function.
    FlashRegs.FOTPWAIT.bit.OTPWAIT = 1;

    However, in the F28069 data sheet, for 90MHz, it says the minimum OTP wait-state is 5 (for 80MHz it is 4) and not 1 as in the example. Should I set it to 1 temporarily as in the example, and then set it back to 5 after osc compensation is complete? Or, should I set it to 5 as specified in the data sheet?

  • I think I found my answer here about the wait-state.  Seems the examples are wrong and have too low of a wait-state for 80/90 MHz. 

    http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/285606.aspx

  • Fulano,

    OK. I think that the application report will probably need to be updated to be more clear, and the F2806x example will have to be updated to use the correct wait-states.

  • Devin,

    In the osc_comp example ... it says the wait-states are critical for correct functionality of the oscillator compensation functions.  I understand that grabbing these calibration values from OTP is dictated by the flash wait-states.  But why does the timing matter here?  The calculations that the osc_comp() functions are performing don't seem to be time-critical.  The values being read are factory values and aren't changing over time.  Anyway, just curious.

  • Fulano,

    Setting the wait-states too low will potentially cause incorrect reads which could lead to incorrect execution. Setting the wait-states really high will eat an unnecessary amount of CPU cycles since there are multiple calls to functions in OTP in the example. 

    Of course another solution if performance is important would be to load the calibration values into RAM one time on start-up. 

  • I will just leave the wait-states at the minimum values specified in the data sheet since oscillator compensation is only performed once at start-up.  Thanks for your time and the prompt responses.