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.

MSP430F6721 ACLK Problems with EMC

Other Parts Discussed in Thread: MSP430F6721

The ACLK is being sourced from REFOCLK and under normal operating conditions, everything is working just fine.   The MCLK / SMCLK are running at 8MHz and the 24bit AtoD is working well at 2MHz.  The LCD is producing good quality and stable measured answers.

I am watching ACLK on PJ.3 with a good quality oscilloscope.

If I apply a significant level of EMC (from an EMPulse - so actual levels unknown) above the µController (near the DVCC / DVSS and analogue supply pins), I can see the ACLK frequency starting to fluctuate badly.  The LCD display becomes very poor and the 24bit AtoD results wander very badly.

These results were first found in a proper certified EMC test-house, where the product badly failed the required >3V/M.

Obviously, as the REFOCLK is the heart of the timing for the LCD and the 24bit AtoD (via the FLL etc), why am I seeing such poor results from this Internal Reference oscillator.

There appears to be some sort of batch issue.  We are now using a large volume of this particular µController and have more than one batch number:  The better chips seem to start with 52ADF3 or 55CC97 and are far less susceptible to the EMC.  Other batch numbers ie: 55CC98 are very poor and are causing problems.

The chip has adequate capacitance around it with large and not so large ceramic capacitors adjacent to it.  Approx. 50µF is across the supply lines and the CVCore  has been increased to 4µ7.  This does improve the situation but not cure on the susceptible chips.   The better chips work well enough with 4µ7 on the supply rails and 470nF as CVCore (the datasheet recommended value).

Any insight to this problem will be greatly received as the development of the project has stalled due to this issue.

Regards

Graham

  • Hello Graham,

    Although the REFOCLK does have greater variance and drift as compared to using an external clock oscillator on LFXT to source the ACLK, I do not believe it to be the source of your application issues but rather a symptom of Vcc vs. MCLK violation caused by EMC disruption of the Vcc. What is your system's supply voltage? Assuming that both the LCD and ADC are not sourced by the ACLK then we know that MCLK/SMCLK are affected by the EMC as well. Although 8 MHz is supported at a PMMCOREVx setting of 0 I would recommend increasing this setting a few levels to help with the EMC noise.

    The performance you are experiencing is not the result of a batch issue. You are already operating at the edge of what is recommended and therefore poor performance is more evident on some batches as compared to others. Additional capacitance on the supply rails (as close to the MSP430 as possible) will continue to improve performance, we generally recommend 10 uF + 100 nF for each Vcc pin. I also advise implementing the suggestions given in the MSP430 System-Level ESD Considerations App Report, including PCB design revisions and the addition of ESP suppression devices: www.ti.com/.../slaa530.pdf

    Regards,
    Ryan
  • Hi Ryan

    Thanks for the reply.
    I need to discuss this a little further. Since my first post, I have created a very simple project to just toggle a port pin at 1/2 Sec rate using a timer running from the ACLK (REFOCLK ~32KHz). ALL port pins have been set to O/P's and the relevant JTAG pin set to O/P ACLK. This still fails even though I have set the port pins to high drive (just in case). I can see the LED toggling rate increase significantly as I apply more EMC from the EMPulse machine. The ACLK signal which was nice and clean without the interference becomes a jittering mess which the OScope cannot properly display, squegging is the best description. If I apply even more EMC then I can mostly stop the chip working. A watchdog reset doesn't help the recovery every time - just occasionally. Under this stalled condition, the REFOCLK is not running and doesn't re-start. Only power removal manages the re-start.
    To clarify the power arrangements: I am running at a properly regulated 2.7V and have lots of capacitance placed around the regulator and the MSP430F6721 as close to the pins as I could track them. The whole PCB is ground-planed where possible (both layers) and plenty of via's to connect the layers. I do indeed have 10µF and 100nF and in some places, greater than 10µF just to prove. My main DVCC + AVCC capacitance is some 50µF in parallel with 100nF caps and I have raised the value of CVCORE to 4µ7 (still about the prerequisite 10:1 from the data sheet).
    I have not yet tried increasing the VCORE above the 0 value so I guess this must be my next step however, will this have an effect upon the REFOCLK as well?

    Regards
    Graham
  • Hi Graham,

    If you could, please output MCLK as well and comment on how it is affected by the EMPulse machine. Also please note that REFOCLK can drift substantially with changes in temperature/voltage and that for most timing-dependent applications it is recommended that an external crystal that is connected to the LFXT be used as the source for ACLK. Increasing Vcore should not have an effect on the REFOCLK frequency but could help stabilize the fluctuations caused by the EMC.

    Regards,
    Ryan
  • Hi Ryan

    Sorry for the delay.  I am now providing the ACLK & MCLK on the JTAG pins and can immediately see that under normal running conditions, the ACLK is at 32.7xxKHz and the MCLK is at 2.1MHz (why not at ~8MHz at this time, I do not know - but never mind).  When the EMPulse is brought near the I/C and the ACLK goes awry, the MCLK also goes wrong, again squegging in the same way as ACLK but at a much higher frequency.  Again the oscilloscope cannot trigger on the mess.

    I am not overly concerned about ACLK drift with V / °C as long as it is still ball park. 

    Regards

    Graham

  • >ACLK goes awry, the MCLK also goes wrong
    How does VCC and/or VCORE look at the same moment? Any correlation?
  • Hi Ilmars, I can see some random spiking on both supply rails when applying the interference - whilst monitoring the ACLK signal. These spikes are a bit disconcerting at perhaps ±1V. There are already several 100nF caps within close proximity of the chip and additionally, 22µF ceramics as well as 22µF tantalum types.
    VCore now has 470nF ceramic as well as 4µ7 ceramic right-up against the pin. The whole PCB is ground-planed on both layers with adequate via's connecting through. DVCC is created by a voltage regulator at 2.7V nominal. I can't correlate the spikes to the ACLK edges. If I monitor MCLK (rather than ACLK) whilst applying the interference, the supply rails appear clean - no spiking. This I find very strange.
    Rgds
    Graham
  • >These spikes are a bit disconcerting at perhaps ±1V.
    This is not typo? ±1V especially on VCORE can cause virtually anything you were dreaming in your worst electronic nightmares. In case of such power surges, issues you describe are not msp430 fault but more likely board/device design/layout fault or just improper testing.

    Are you doing EMC tests according some standard requirements/methodology?

  • Hello Graham,

    I'm in agreement with Ilmars, ±1V on the Vcc/VCore lines is far too much to expect normal device operation. With the amount of decoupling capacitance described I have to believe that there is a problem with the hardware/board design layout that is causing the MSP430 to fail.

    Regards,
    Ryan
  • I thank both Ilmars and Ryan for their replies.

    I still don't understand why I only see the supply rails spikes whilst I am also monitoring the ACLK (with the same oscilloscope) BUT I don't appear to get these spikes whilst monitoring the MCLK instead of the ACLK.   The layout is extremely similar to very many of our products using this same I/C or another TI devices.  Plenty of capacitance of various types are fitted as close to the I/C as is reasonably possible and the tracking short and wide.  There is an almost complete ground-plane under the I/C and the non-component side also carries an extensive ground-plane.  Many via's are placed to ensure the ground-planes are as electrically close together as possible.   This is the approach we always use with a variety of TI µControllers and don't usually have these types of issues.

    I will study the PCB layout further and see if improvements can be made but due to the density of component placement, it is very unlikely I can improve upon the layout we have already.   The regulated PSU section is used in very many of our products and is always reliable / trouble free.

    Regards

    Graham

  • >I still don't understand why I only see the supply rails spikes whilst I am also monitoring the ACLK (with the same oscilloscope) BUT I don't appear to get these spikes whilst monitoring the MCLK instead of the ACLK.

    Are you sure that what you see on the scope screen is what actually happens in the circuit you measure? This could be measurement, not circuit problem. You could be measuring EMC of your probe or even worse - measuring lab equipment ground loop artefacts.

    You are advised to power DUT from battery, re-check earthing of equipment, do not use ground lead of probe but clip-on spring which ensures that probe ground connection is as short as possible and close to probe tip, take extreme care while using more than single channel of the scope - check that waveforms do not change just when you connect 2nd probe.
  • Hi

    I have placed an aluminium sticky-backed pad above the MSP and most of the surrounding components and whilst it doesn't completely fix the problem, it is much reduced. This pad doesn't connect to anything - just acting as a local screen. Therefore I have decided to live with the levels of interference for the present time and continue with the firmware. To note: the product is battery powered anyway so no earth loops etc. The scope leads were possibly picking up some of the interference, but minimally so.
    Thanks for all your help and suggestions - best regards
    Graham

**Attention** This is a public forum