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.

MSP432P4111: RTC on Launchpad has low precision

Part Number: MSP432P4111

Hi,

FYI,

RTC on my (exemplar of) MSP432P4111 Launchpad has very low precision (-1 min/day). This abnormal precision was never the case for other Launchpads (~ 1 sec/day). The compensation coefficients have not been applied to RTC_C module. May be the RTC module is missing one clock tick per second. The RTC interrupt is called every second to clear the RTC flags.

Regards,

Alexey

  • Hello Alexey,

    There is a lot of missing information here. However to clarify, does it perform as per expectation when the compensation coefficients are applied. Every device behaves slightly differently, hence it may be possible that till now you may have not seen an issue, except now.

    I would strongly advise to apply the compensation and then check.
  • I tried earlier to compensate with coefficients, but had had bad results. I need to dig further to find out: is it a LF crystal problem or RTC_C module problem. By the way, this is an XMS version of the chip installed on Launchpad, so maybe this cannot be reproduced in the final silicon.

    Alexey

  • Hello Alexey

    It maybe the problem, but first let us look at the LFEXT specifications that you have selected.
  • The code is representing RTC settings only and not actual program execution. RTC readings is actually called by a timer.

    RTC interrupt:

    void RTC_C_IRQHandler(void)
    {
        RTC_C->CTL0 = (RTC_C->CTL0 & ~(RTC_C_CTL0_KEY_MASK |  RTC_C_CTL0_RDYIFG |  RTC_C_CTL0_TEVIFG)) | RTC_C_KEY;
        RTC_C->CTL0 = RTC_C->CTL0 & ~(RTC_C_CTL0_KEY_MASK);
    }
    

    RTC config:

    PJ->SEL0 |= BIT0 | BIT1;
    CS->CTL2 |= CS_CTL2_LFXT_EN | CS_CTL2_LFXTDRIVE_0; // LFXT on

    CS->CTL1 &= ~CS_CTL1_SELA__REFOCLK; // use LFXT

    RTC_C->CTL0 = RTC_C_KEY | RTC_C_CTL0_RDYIE | RTC_C_CTL0_TEVIE; RTC_C->CTL13 = RTC_C_CTL13_HOLD | RTC_C_CTL13_MODE | RTC_C_CTL13_BCD | RTC_C_CTL13_TEV_0; RTC_C->CTL13 = RTC_C->CTL13 & ~(RTC_C_CTL13_HOLD); RTC_C->CTL0 = RTC_C->CTL0 & ~(RTC_C_CTL0_KEY_MASK);

  • Hello Alexey,

    What is the LFEXT crystal you are using? Can you please provide the link to the datasheet?
  • It is a standard LF crystal installed on the Launchpad:
    Epson X1A0001410004 FC-135R 32.768KHZ 9PF
    Actual mark on the case: A731N.

    Regards,
    Alexey
  • Hello Alexey,

    The configuration for the RTC seems fine to select LFEXT. I will ask my colleague to help you out or have some other ideas to test.
  • The problem solved by replacing crystal loading capacitors (used the same 22 pF). Uncalibrated precision is now within 2 ppm (+25 deg. C).

    Regards,
    Alexey
  • You may want to think about if that's indeed your problem. Those crystals have very low pullability.

    I would look into why a 9pf crystal requires 22pf to run on spec.

  • The situation is still unknown due to RTC/crystal gives good accuracy (~2ppm) for as long as 14 hours and then is loosing 5 secs in 1 hour.

  • Another crystal - RTC is loosing 5 sec/hour. Looks like something happen in the MSP432P4111 chip.

  • One more thing: the actual testing environment: Most of the time chip stays in deepsleep mode, refresh rate - 1 sec; power source - supercap; so VCC is constantly going down at rate of 250mV/12 hour. The RTC behaves unusual when VCC < 3.02V.
  • Hello Alexey,

    A few points to note here

    1. The LaunchPad most probably has a XMSP432 device which is not a fully characterized and qualified device
    2. The LaunchPad is meant for software and feature evaluation of the device. The actual testing must be done by the customer on their system using all qualified parts.

    Lastly swapping out the caps is not really the solution here. There is something else that is happening at 3.02V. Please check if your parameters for device configuration are supported at 3.02V, i.e. clocks, core voltage. At this point instead of using the crystal, you may want to check the device using a single-ended clock source which is not dependent on the drive from the device.
  • Actually, I early pointed out that XMS432 chip is installed and I've changed crystal also (all steps were needed to isolate the problem). If there are no specific restrictions, solutions based on MSP432 is capable to work fine down 1.62V. RTC has its own isolated access to the crystal frequency by the BCLK, so it can work in LPM3.5 mode and is fully independent from other clocks, core voltages, etc. I think the problem is in the inverting amplifier feeding crystal doesn't have reference voltage source. It is connected to VCC instead, like the LCD_F doesn't have the charge pump.

    Regards,
    Alexey
  • Ok, all works fine at least down to 1.61V with this crystal drive settings:
    CS->CTL2 |= CS_CTL2_LFXT_EN | CS_CTL2_LFXTDRIVE_3;

    Regards,
    Alexey

  • At the end, the problem hadn't been solved for the voltage range from ~3.09V to ~3.00V.
  • Hello Alexey

    For the range of voltage specified what does the Crystal Oscillation look like?
  • I didn't view the oscillation through the oscilloscope, but such problem persist with different verified (on other chipset) crystal. Practically, in specified voltage range the RTC is loosing ~5 sec/hour. In other voltages crystal works exceptionally precise (just in sync with compensated crystal after 96 hours).

  • Hello Alexey

    Normally crystal characterization is performed by the crystal manufacturer. However if the device is proven to be working earlier, then you may want to check by changing the crystal to see if it is a crystal issue.
  • I have changed the crystal from proven FR5994 Launchpad and have got the same bad result. The problem is not in the crystal. I have changed even supercap and all other external hardware. The problem still persist.
  • "Looks like something happen in the MSP432P4111 chip."

    Unless this is a wide spread problem, it is far more likely that the software is to blame.
  • Danny F,

    This is E2E forum. The feedback to the TI's engineers is essential to fix problems on newly available chips. Such risks of chip malfunction are accountable as they are not production-ready. This thread is intended specifically for this purpose.

    Alexey
  • Hello Alexey,

    The point is well noted. Since it is not possible for every pre-production device to be the same as the final production device due to stricter checks during manufacturing test process, it may be possible such an issue to happen. There is a return process for such failures when seen in the field, so we will keep a look out and update the thread in case we see an issue or have a suitable resolution.

    In the meantime, you may want to check another LaunchPad for MSP432P4111 to see if the issue is there or not.
  • Amit,

    I was interested in electrical characteristics of this chip in specific ultra-low power conditions. Right now part of the project is "growing" based on MSP432, but in the end I plan to change the chip to more integrated solution like CC1352. For now CC1352 is not suitable for that by many aspects, but I hope all specific requirements will be fulfilled within a year.

    But for now, look what CC1352 official issue have: "Engineering samples revision A (rev. 1.0) of CC13x2 devices do not work with SmartRF Studio. This can be seen when starting Packet TX. It will fail with the command status = 0xbad0".

    I understand, that there should be a "window" to change characteristics of the chip to bring new capabilities, but this stops me from buying the Launchpad, as such capabilities/specifications/characterizations they don't have for now. But I declared such requirements early and I keep in touch with TI's roadmap and behave accordingly. :)

    Alex

  • "but this stops me from buying the Launchpad, "

    I would second that, and I think TI should re-think why it has those launchpads out there. To me, they are great marketing tools for engineers / engineer-to-bes to see what the chips are capable of doing so they can deploy them in their next project. In general, TI has done a great job utilizing that as a marketing tool, for other chips / products.

    when it comes to the launchpads, TI seems to have taken a different strategy, treating those pads as beta-testing ground, with untested / poorly tested chips. sending them out is one of the most effective ways to destroy your reputation and turning off future customers and getting yourself shut out of future designs.

    If I were to manage the launchpad project, I would have put forth my best and most reliable / robust chips, instead of those "experimental silicon". TI is spending money and resources to hurt itself.
  • I like "sneak previews". As long as they're labeled as such, I can work that into my expectations. If you don't want to try early versions, then don't buy them.

    The Launchpads are inexpensive enough so that when the "real" devices come out I can throw the old ones away (even if I can never actually bring myself to do that (:-))).
  • Looks like the problem disappeared after some week of chip power-on in these conditions.

**Attention** This is a public forum