• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 1022 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

rm46L430: How to correctly trim the HF LPO Oscillator

Mark Kingston
Intellectual 320 points

Part Number: RM46L430
Other Parts Discussed in Thread: HALCOGEN

The RM46 Reference Manual SPNU514B–April 2015, section 10.4.6 Trimming the HF LPO Oscillator says:

'During device test, a trim value is written into the one-time programmable section of the flash memory (OTP), address 0xF008_01B4.'

It also says:

'When trimming the HF LPO, it is recommended to step the trim value so as not to make a large change to any TRIM setting.'

The HalCoGen example code:

  • Checks to see if the 16-bit trim value is '0xFFFF', in which case it does not apply it.

  • Does not change the trim value in steps.

I cannot find any information regarding the LPO trim in the SafeTI Library / Safety Manual or anything relevant in a previous community post, so my questions are:

  1. Is there a requirement to use a trim value of zero if the OTP read is 0xFFFF?

  2. What is the recomended maximum step?

  3. What is the recomended pause between steps?

  4. Where can I find the documents that specify these requirements?
  • 0
    TI__Guru 59540 points

    Hello Mark,

    Mark Kingston said:
    Is there a requirement to use a trim value of zero if the OTP read is 0xFFFF?

    No. there is no requirement to use a trim value of 0 if the OTP read is 0xFFFF. If the OTP trim value reads 0xFFFF, it is in its default erased state and this is, most likely, an indication of a missed process step in the device manufacturing test process. If a trim value of 0xFFFF is read, it is highly recommended to reject that device/assembly and return the device to TI for failure analysis/fault determination and corrective action.

    Based on the LPO Trim code that is provided with Halcogen, there is an opportunity to add a check for the LPO Trim = 0xFFFF in one of the user code sections to isolate the device by entering a while(1) or forcing an nERROR pin status or to add code to determine a custom Trim value by comparing to OSCIN using the DCC. As stated above, my recommendation would be to enter a safe state and force an nERROR notification.

    Mark Kingston said:
    • What is the recomended maximum step?

    • What is the recomended pause between steps?

    • Where can I find the documents that specify these requirements?

    Unfortunately, we did not add any details regarding what types of steps to use. Generally speaking, this is an issue when there is a very large change in the trim value. The resulting issue is a fault occurs from the Clock Monitor circuit due to the rapid change in the HF LPO clock. The issue was discovered when some early devices didn't have a TRIM value programmed (0xFFFF) and the code was loading the 0xFFFF value as the HF LPO Trim. This caused a drastic change in the LPO frequency and a resulting Clock Monitor Failure.

    Also, generally speaking, we have not seen an issue in the field with the Halcogen generated code. I believe this to be due to the relatively small trim values needed on each device.

    A second approach would be to disable the Clock Monitor Feature when the TRIM value is updated. This can be done using the CLOCK TEST register. Specifically to briefly disable the LPOCLKMON operation during the TRIM value update, the RANGEDETENASSEL and RANGEDETCTRL fields can be used. Once the LPOCLKMON circuit is disabled, the trim can be updated and the sudden change will not result in a fault regardless of the size of the change in Trim. Code to disable the LPOCLKMON and re-enable it after the trim update can be added in the user code sections within the LPO Trim function generated by Halcogen.

    Note: I have also copied submitted this as an issue to our documentation team and to our Halcogen team so that it can be properly addressed in both documentation and the Halcogen code base.