• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 81 subscribers
  • Views 1823 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.

MSP430FR5739: High consumption at power ON

Marco Micheli
Prodigy 80 points

Part Number: MSP430FR5739

Dear all,

After 50k pieces installed we got a strange behavior at the power ON of a MSP430FR5739

The application is a lighting control power through an 1-10 line that came from a AC.DC power supply, used as current generator for a string of LEDs.

The AC-DC could provide only a small amount of current, roughly 100-150uA, that produces a ramp on the capacitors on the PCBA.

From 0 to 10 V it takes roughly 1 seconds.

The microprocessor has a peak of current consumption at power ON. During the develop a lot of time was used to find a suitable order and settings in order to lower this peak.

In a lot of 2500 pieces it seems that, at the very beginning, when the voltage is increasing on the Vcc pins of the uP, the uP starts consuming too much letting the AC-DC find an equilibrium at roughly 1.6-1.8V. The uP, clearly it is not already started.

It seems that, once we found a “defective board”, if we move the microprocessor on one other board the defect follow the uP,

 is connected to the power supply

 

Therefore:

1. Which are the starting currents when the MSP430FR5739 RHA 40pin is powered on?

2. Which variations of this parameter can we expect in production?

3. Are there known bugs that can lead to "abnormal" absorption

4. How can we conveniently set up the compiler?

5. Could you please support us in order to find an ideal order for the initial instructions to have the lowest possible peak power consumption at power ON?

6. Behavior "seems to be" highlighted with Lot BATCH NR components:

[)> 06P1PMSP430FR5739IRHAR6P2PJQ2500V00333171T4347111ZD74WTKYD163631T6793173CL620LDM621LUSA22LQAB23LPHLEG43Z3 / 260C / 168HR; //; 101616L15187K

7. The increase in consumption seems to follow the micro. An "abnormal" consumption card has returned to a common behavior after replacing the micro. The micro replaced replaces the abnormal consumption on the board where it was reinstalled.

8. How can coexist the 50000 pieces produced so far with the problems that we are now finding?

9. Electronic noise could bring the micro in the above described conditions.

10. How to connect the reset. Currently the PCBa have only a 49kOhm pull-up on reset, no capacitor to ground

11. Could you suggest a PMIC, low dropout able to produce the 2.04V to power the micro capable to resist up to 15V and with minimum quiescent current of few uA? It should also have a monitor circuitry able to enable it only once the input voltage it’s over 2.1V, possibly with an accurate monitor of the input voltage, to enable its output only for voltage voltages above 2.1Vdc

 

 

Best regards

  • 0
    TI__Guru* 84661 points

    Hi Marco,

    We do not provide a specification for the startup current for this device. However, with as little as 100uA being able to be provided from your supply, I am not surprised that you would have issues. If you see the Active mode currents in the device datasheet, you'll see that even for 1MHz operation with 75% cache hit ratio, you'll see a typical current of 250uA. So I don't think this supply solution will be reliable.

    A few things happen at device startup that consume additional current:
    1. Vcore cap has to charge
    2. Bootcode has to run (executing code so similar to active mode)
    3. Before GPIOs are initialized by code execution, they are floating pins that can cause a lot of current consumption as well

    Additionally, on the MSP430FR5739 there is the PORT16 erratum that can cause additional current consumption at startup - see the errata document www.ti.com/.../slaz392. Basically it says that if there is a RST pin event during boot code execution, when the part starts back up you'll see some GPIO pins driven low for the duration of the boot code (approx. 500us). That can cause additional current consumption, especially if you have external components on these pins. You should ensure that you aren't getting repeated resets on the RST pin, and check for noise there. Put a 2.2nF cap on RST to help prevent some noise, and keep the trace as short as possible. Is there a noise source in your design?

    So to summarize for your questions:
    #1, #2: this is not a datasheet spec so I can't comment. However 100uA supply is too low if you even just look at active mode current of the device.
    #3: PORT16 erratum www.ti.com/.../slaz392
    #4: I am unsure what you are trying to ask for this one. Are you asking about compiler optimizations?
    #5: Setting all floating pins at the very beginning of the program would be a good step, but the peak current could be coming from before you even get to user application code because of the Vcore cap charging and the bootcode running. You also could externally tie unused floating pins to ground so that they are not floating during the device startup and bootcode execution.
    #6 & 7 & 8: this could be basic device variation on startup time. The datasheet specifies 1.6ms as typical wake-up time from BOR or power-up to active mode, but this is only a typical number. Some parts could take longer and this could mean it is longer before your user code can run to initialize pins to not be floating for example.
    #9 & 10: For PORT16 erratum, if there is no cap on the RST line and it is not driven by an external IC, this could mean there are glitches on RST that cause the issue. I would recommend a 2.2nF cap on RST. Is there a noise source in your design?

    For #11, I'll have to do some searching but you may also want to ask in the (DO NOT USE) PMIC Forum


    Regards,
    Katie

  • 0 in reply to Katie Pier
    TI__Guru* 84661 points
    Hi Marco,

    Did this answer your question or is there more we can do to help?

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Prodigy 80 points
    Honestly it doesn't help.

    Our business must go ahead and I've fear that "abnormal " consumption could bring to severe conseguences.

    Please help us in order to understand what we can do clarify this behavioir for the next productions.

    If we understand, maybe, we can intruduce some correctives and save the project that could grow and remain active for several years.

    We could introduce a modification in the LDO, for instance, lowering its quiscent current and finding a way to wake up it only when the voltage is high: could you suggest one of your items?

    Could you provide us a support in order to chose the best compiler configuration for Low consumption at Power ON?


    Could you provide us a support in order to chose the best order of the initial lines of code for Low consumption at Power ON?

    Tank you Very much

    Marco Micheli
    +39 339 270 8447
  • 0 in reply to Marco Micheli
    TI__Expert 7015 points

    Hi, Macro,

    Could you tell us what is the de-cap on the DVCC pin of FR5739? 100-150uA current to supply FR5739 is really small. Only the low power mode can accept this working condition. Is the application mainly working in low power mode such as LPM3?

    As Katie mentioned, the start-up current is mainly from the ROM boot code running. The running will last about 500us. The peak current will varies some over the silicons.

    To cover the variation, the de-cap for the DVCC should be big enough so that the de-cap can accumulate enough power to cover the consumption of boot code running. After the boot code running, user code will start. It is important to configure the GPIOs as soon as possible to fixed voltage level to save power consumption, initialize the clock system with low frequency, and enter the low power mode LPM3 immediately.

    After wake-up, run the code with low frequency MCLK, and make the run time as short as possible before entering LPM3 again.

    Please try to increase the de-cap value and optimize the firmware as recommended above, and let us know if this help or not. Please note, addinte the de-cap value will increase the power-on time, maybe several hundred ms to 1s. But I think customer application can accept the trade-off, right?

    Thanks and Best regards,

    Lixin Chen

**Attention** This is a public forum