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.

MSP430F6736: ADC10 conversion causes a WDT reset

Part Number: MSP430F6736

Hi

i am using the ADC10 to monitor the voltage from a battery on AuxVcc3.
So long as the battery voltage is above about 1.6V i get a reading.

However, once i start dropping the battery voltage (the 'battery' is a variable power supply) below 1.6V the conversion doesn't happen and the watchdog timer is triggered.
Its almost as if the ADC10 itself is being powered from the AuxVcc3 line.....is it???

These are my settings:

AUXADCCTL |= AUXADCSEL_3 | AUXADCR_0 ; // select auxVcc3 as input to ADC10. 18Kohm load resistance
AUXADCCTL |= AUXADC;                                          // switch on the aux supply input to ADC10

use internal ADC osc with pulse sample mode
use 32clks for sample & hold time
single conversion
get result in interrupt.

ADC10CTL0 = ADC10SHT_3 | ADC10ON;                                                            // S&H=32 ADC clks, Enable ADC10 but keep ADC10ENC = 0
ADC10CTL1 = 0 | ADC10SHP | 0 | 0 | ADC10SSEL_0 | ADC10CONSEQ_0; // s/w trig, pulse sample mode, no inversion, no clk div, modclk, single ch/conv
ADC10CTL2 = ADC10RES;                                                                                      // no predivision, 10-bit conversion results, unsigned result, no reduction in sampling rate
ADC10MCTL0 = ADC10SREF_0 | ADC10INCH_12;                                          // Ref=AVcc & AVss, channel 12 is Aux supply input...NOT 11!
ADC10IE |= ADC10IE0 | ADC10TOVIE;                                                                 // Enable ADC conversion complete interrupt
ADC10CTL0 |= ADC10ENC | ADC10SC;                                                              // Sampling and conversion start

what am i doing wrong??

thanks in advance.

  • Hi Moshe,

    This is something I haven't seen before, but I can help debug with you. Can you provide more information on the WDT interval and where you reset the WDT based on the ADC conversion?

    Also, could you provide an example with the minimum code necessary to cause the issue to occur so I can test it out on my end?

    Best regards,
    Caleb Overbay
  • Hi Caleb...thanks for responding (i didnt see your response before i wrote mine)

    But I will answer my own issue for others to know.

    Not mentioned above is the use of RTC_C....this operates off AuxVcc3..that in itself isnt a problem, but, i also had an interrupt running on RTC_C and THAT was the problem.
    By removing that interrupt the ADC worked perfectly down to zero voltage on AuxVcc3....of course i now have a workaround to write for my RTC but i can live with that.

  • Hi Moshe,

    Thanks for updating the post with your solution. It's good to hear you were able to figure it out!

    Best regards,
    Caleb Overbay
  • Hi Caleb

    There was an additional factor i didnt mention, i had to wait at least 4secs (after switching off the Aux charger & before starting the ADC) for whatever capacitance there was on AuxVcc3 to drain. If i only waited 3secs i didnt hit the problem.

    But i also just realised what that specific interrupt was...it was the RTC oscillator interrupt enable fault!
    So now i'm puzzled why that specific interrupt event causes the WDT to kick in but the RTC_RDY doesn't?
    And even MORE puzzling...if i put a breakpoint on that specific interrupt in the RTC_C_ISR it repeatedly traps the osc failure but doesnt cause a WDT to trigger!

    cheers
  • Hi Moshe,

    When you say "it was the RTC oscillator interrupt enable fault"do you mean it was a RTC oscillator failure interrupt?
    Are you using the WDT in your application or are you disabling it at the beginning of you application?
    Also, how are you sure it is a WDT that is causing a reset or that the device is resetting at all? Have you check the SYSRSTIV register for the source of the reset?

    Best regards,
    Caleb Overbay
  • Hi Caleb

    It took me a while to recreate the issue...
    These taken together seem to cause the issue to appear:
    1. WDT mode set to interval mode NOT watchdog timer mode....it didnt happen when set to WDT mode!
    2. RTCCTL0 enable oscillator fault.
    3. wait 5secs after setting the ADC and before taking a reading. But the program doesn't actually get to the point where the ADC is set to take the reading, it just needed the 5 secs to allow some capacitance to drain on AUXVcc3.

    So in answer to your questions:
    Yes, i meant RTC oscillator failure interrupt.
    Yes, i am using the WDT.
    Yes the SYSRSTIV value indicates a watchdog "password violation." The reason the WDT itself is causing the reset is because I am causing the WDT password violation within the WDT ISR (otherwise it merely returned to the point of the error and i require the MSP to be reset).... (ie i set WDTCTL = 1)

    Incidentally, the reason for wanting to trap the WDT is to store the address of the code causing "a timeout". The finding of a WDT trigger via an oscillator fault was unintentional!

    So now after having done a bit more reading i can surmise that what is happening is "precisely what is supposed to happen" namely the auxillary oscillator stopped working when i switched to the under-voltage battery and caused an interrupt that in turn is trapped by the WDT.

    However, in that further reading, i noted that there are TWO vectors for the WDT depending on the mode....so how can one trap a WDT interrupt in WDT mode rather than interval mode??

    cheers
    moshe
  • HI Moshe,

    You're correct that there are technically two vectors for the WDT. However, as can be seen in Table 9 of MSP430F6736 datasheet (slas731.pdf), one interrupt vector leads to a Reset(0xFFFE) and the other is the WDT interval mode vector.

    The first vector will always result in a device reset (PUC) and cannot be trapped before doing so. The only way to trap a WDT is to use it in interval mode.

    Best regards,
    Caleb Overbay

**Attention** This is a public forum