• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 2 answers
  • Subscribers 80 subscribers
  • Views 626 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F2618: ADC12 Control Registers Corrupted

Joerg Plamper
Prodigy 80 points
Part Number: MSP430F2618

Hi,

I have a PCB which is equipped with an F2618 running software which has been working fine for years. Now, all of a sudden three samples of these boards failed in a row. I found out that this is due to the ADC12 module and the latter in turn is failing because the associated registers are refusing to remember their intended content. I did not investigate the very details yet but, for example, the ADC12CTL0 register gets corrupted by writing to ADC12CTL1. Obviously, the ADC12 will never produce an interrupt when I am not even able to switch it on or at least permanently on.

This is apparently not a software issue because the same executable works fine on former samples, On the other hand, I can not conceive that a unit with such a malfunction can leave the factory: The ADC12 must have worked at least when the calibration data were measured, or am I wrong with this?

So what external condition can cause such a behaviour? It must be something that happened between the device having been tested and its first programming on my desk.

Best regards

J. Plamper, Sensor Line GmbH

  • 0
    TI__Mastermind 26410 points

    Hello Jorge,

    How many units are you talking about?  Has anything recently changed in the PCB production process?  

    Can you swap the MSP430 from a good board and bad board and confirm it follows the device?  

    This report sounds like an extremely strange issue and I've never heard of such behavior before and I don't see any such errata.  It's possible that the device has been damaged during assembly somehow, but it would be strange to present in such a specific way over multiple boards.  

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Prodigy 80 points

    Hello JD,

    These are samples #2, 3 and 4 out of a prototype batch of five. It is the second such batch implementing minor modifications which I can not conceive to be related to the problem, especially as Sample #1 is working properly, as did the whole first batch with the same software.

    We obtain these units from a manufacturer who does the PCB and assembles all SMD components, especially the controller. I am then adding the larger through-hole components (connectors) by hand.

    Two things are different with respect to Sample #1:

    1. It was the first time I succeeded programming the flash without erasing the TLV structure in SegmentA. My programming software had a wrong default setting before.

    2. I used a new soldering iron.

    The latter would appear quite suspicious to me if I could only conceive how a soldering iron can selectively affect the ADC12 control registers while leaving everything else working fine.

    Best regards

    Joerg

  • 0 in reply to Joerg Plamper
    Guru 88460 points

    Item (1) caught my eye. Are you using the calibrated clock constants in InfoA (CALDCO and friends)? If so, are you fairly certain they're intact now?

    Observed behavior (from many years ago) is that overclocking the MCU doesn't cause it to lock up, rather it produces effects best described as [engineering term] "weird" -- random code branches, bits popping up in memory where they don't belong, that sort of thing.

  • 0 in reply to Bruce McKenney47378
    Prodigy 80 points

    Hello Bruce,

    No, CALDCO and friends are not used. I am just attempting to calibrate the ADC12/DAC12.

    On the other hand, the controller runs at 16 MHz with a crystal. This frequency must be ok, because otherwise I could not receive serial output at the correct Baudrate. May 16 MHz be too much?

    Best regards

    Joerg

  • 0 in reply to Joerg Plamper
    Guru 88460 points

    Per data sheet (SLAS541K) Figure 1, 16MHz at 3.3V is fine. Watch out for power supply ramp time (we tried that once too).

    At this point I defer to the Wizards.

  • 0 in reply to Joerg Plamper
    TI__Mastermind 26410 points

    Hello Joerg,

    Sorry for the delay, wanted to check back in.  Everything you've shared sounds okay. Were you able to get these units working?  

    If not, what programming software are you using and what settings did you change?  Did you use these new settings for unit #5?

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Prodigy 80 points

    Hello JD,

    I am using an Olimex MSP430-JTAG-TINY-V2 programmer with associated program Olimex.exe. Originally this came up with all options under "Operations" checked, so the data memory was programmed (i.e. erased) too. Unchecking "Data Memory" did not help because under "Calibration area" the boundaries were incorrectly set to 10F0 to 10FF. Setting them to correct 10C0 to 10FF then left the calibration data intact.

    Currently I am not daring to handle the #5 unit at all. It is my last one and I want to have at least a hint for what may be wrong here. Maybe it is my fault after all. The "wizards" at TI are contemplating at the moment.

    Best regards

    Joerg

  • 0 in reply to Joerg Plamper
    TI__Mastermind 26410 points

    Joerg,

    I'm not familiar with Olimex, but that sounds okay.  

    Can you try running some basic ADC example code on your unit?  You may have to change the GPIOs to match your board.   There are a bunch of ADC examples for the MSP430F2618 here: http://dev.ti.com/tirex/explore/node?node=APz5FL7xC-GKZb-QFpwq9g__IOGqZri__LATEST 

    Is installing a new MSP430 an option?  Again, as you thought orginially thought, it could have been damaged somehow.

    Thanks

    JD

  • 0 in reply to JD Crutchfield
    Prodigy 120 points

    What clock source are you using for ADC12?  We use loads of 2417's and 2617's in ADC-intensive applications, and never have a problem with them.

    The ADC clock is specified as 0.45 to 6.3 MHz., typically 5 MHz.

    We are also using a 16 MHz crystal: SMCLK is divided by 2 for 8 MHz, and the ADC clock is SMCLK / 2 to give 4 MHz.

    Another thought is that the Olimex usually programs from a hex file (we also have one of these programmers).  Are you sure that your hex file is intact?  You might try recompiling and compare the new hex file with the one you have been programming from.

    Hope this helps.  Ray

  • 0 in reply to Raymond Wales
    Prodigy 80 points

    Hello Ray,

    We have also been running lots of 167's 169's and 2618's without problems - at 8 MHz. Only now we noticed that this exceeds the specification for the ADC12 for full accuracy. Never had any issue with this.

    Reducing the ADC clock frequency was already suggested by TI but it didn't resolve the problem. It is not for the accuracy but for the ADC working at all. Nothing there to check for accuracy, you know.

    It is guaranteed that the hex file is allright, because I have unaffected units which are running the same executable just fine.

    Best regards

    Joerg

  • 0 in reply to JD Crutchfield
    Prodigy 80 points

    Hello JD,

    Of course I can try some examples. But what use is succeeding to set up the ADC in some way that doesn't help us? Nevertheless, thank you for the link.

    Installing a new controller will surely be necessary. We must just ensure somehow that this one will not be damaged again.

    Best regards

    Joerg

  • 0 in reply to Joerg Plamper
    TI__Mastermind 26410 points

    Hello Joerg,

    The original issue says that the ADC registers are not holding their values.   Running the code example can confirm if this is a software or hardware problem.  If the code examples don't work either, then the device is surely damaged.  

    As for what damaged the device, that is an unknown. ESD and over-voltage are by far the most common culprits.   

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Prodigy 80 points

    Hello JD,

    Thank you for your ongoing interest, but we just resolved the issue.

    Hold on tight and believe it or not: The problem was caused by the AVCC pin of the controller not being connected. This does not only cause failure to properly define the ADC control registers but also the controller to draw about 240 mA of excess current at its DVCC pin.This in turn will pull your supply voltage down (in our case to 2.65 volts) and mislead you to the conclusion that there is something wrong with your power supply. But simply connect AVCC and everything is all right. The controller does not appear to be damaged.

    I am aware that I once claimed that the power supply was at 3.3 volts. I apologize. This was measured with a working unit, not a failing one.

    Absolutely no clue how this phenomenon works in detail. Anyway this disproves any claim that everything can be found out the Sherlock-Holmes way. No, my dear Watson.

    Best regards

    Joerg

  • 0 in reply to Joerg Plamper
    Prodigy 120 points

    Hi again Joerg

    Thank you for posting your solution to your problem.

    This has caused great relief in our laboratory!

    Best Regards

    Ray

  • 0 in reply to Raymond Wales
    Prodigy 80 points

    Hello Ray,

    Glad to hear that this helped you somehow.

    I am sure Mr Dietmar Walther of TI won't object to me sharing his comment on this. He wrote:

    "And yes it is explainable if the AVCC is not applied internal nodes draws currents via parasitic cross connection if analog parts gets used. This can cause internal voltage dips on the digital supply (even instruction depended). This again cause a clock to supply violation or simply an overclocking. And this cause unpredictable digital behavior (even if every digital behavior is analog in the back)".

    Hope this also helps a little.

    Best regards

    Joerg

**Attention** This is a public forum