ADuC7024 ADC - Misc questions

Hi,


I have a few questions regarding the behaviour of the ADC peripheral on the ADuC7024 that I hope can be commented on:


i) After an ADC conversion has completed (ADCReady = 1) are the contents of bits 0 to 15 in ADCDAT all 0 or other/undefined?


ii) Data sheet Rev C, P44 says that reading ADCDAT clears ADCReady (ADCSTA, Bit 0). Does this also clear the ADC Channel (bit 7) in IRQSIG?


iii) With ADCCON configured for conversion on Timer 1 (bits 2:0 = 001) is it acceptable to read ADCDAT after a previous conversion has been performed (ADCReady = 0) and while a new conversion is in progress (ADCBUSY = 1)? I want to avoid the possibility of reading a value that is neither the result of the previous, or current conversion, such as when the result is being transferred internally to ADCDAT?


iv) What happens if ADCCON is written to/changed, while an ADC conversion is in progress (ADCBusy = 1) - does it affect the conversion in progress?


v) What happens if ADC channel is changed (ADCCP) while an ADC conversion is in progress (ADCBusy = 1) - does it affect the conversion in progress?


Thanks.

  • 0
    •  Analog Employees 
    on Mar 4, 2011 5:32 PM

    (i) Take the value of bits 15-0 as undefined. there content is meaningless.

    (ii) IRQSIG will be cleared by this operation. IRQSIG is used as the input to IRQSTA - once an interrupt source is triggered, it is latched into IRQSTA and the relevant bit in IRQSTA will not get cleared until the interrupt is fully serviced. If you want to determine if an ADC or any other interrupt needs to be serviced then read the IRQSTA register and not IRQSIG.

    (iii) Yes, it is acceptable to read ADCDAT in this way - you just need to make sure that the previous conversion is complete.

    (iv) Writing to ADCCON when a conversion is under way will cause the current conversion to stop and a new conversion to start.

    (v) Same as (iv)

  • Thanks for the answers. I've follow up questions on two of the points:

    i) The reason behind this question is that I was thinking of the situation of reading out ADCDAT value and using it directly in say a digital filter as below, FilterValue is 32 bit unsigned, and whether the masking out of the lower 16bits of ADCDAT was required. I'd rather not include the mask operation unless absolutley essential. If the lower 16 bits of ADCDAT were all 0 (not stated in the data sheet) then I would leave it out.

         FilterValue[i] = FilterValue[i-1] + ((ADCDAT & 0x3FFF0000) >>5) +....

         ProcessFilter(FilterValue>>16);

    ii) I Always thought IRQSTA = IRQSIG & IRQEN, and didn't realise bits in IRQSIG and IRQSTA were latched differently. So are you saying that when leaving an interrupt handler (IRQ_Handler) then all IRQ bits that are 0 will have the corresponding bits in IRQSTA cleared automatically by the processor? Does this clearing of IRQSTA bits on exiting the ISR depend on the corresponding bit(s) in IRQEN being set?

  • 0
    •  Analog Employees 
    on Mar 16, 2011 9:23 PM

    1) Unfortunately, we can't guarantee that ADCDAT[15:0] will always be 0x0000 - you will need to mask these bits.

    2) An example here may work better.

    If you have an external interrupt enabled and you pulse the interrupt pin, the IRQSIG bit associated with the external interrupt will stay =1 as long as the interrupt level is asserted - as soon as the pin is de-asserted, this bit in IRQSIG will clear to 0.

    However, the same bit in IRQSTA will stay set until the IRQSTA register is read in the IRQ handler routine - even after the pin has de-asserted.

  • In this last example of IRQ processing you say "the same bit in IRQSTA will stay set until the IRQSTA register is read" but previously said "it is latched into IRQSTA and the relevant bit in IRQSTA will not get cleared until the interrupt is fully serviced". These seem like different behaviour.

    I can't see how reading IRQSTA would clear any of its bits, as determining the source of the IRQ in the ISR, as below, involves reading IRQSTA and in that case after the first read then all other tests would fail.

    if ((IRQSTA & TIMER1_BIT) != 0)
    {
    }
    if ((IRQSTA & UART_BIT) != 0)
    {
    }
    if ((IRQSTA & ADC_BIT) != 0)
    {
    }

    :

    Could you clarify when and which bits will be cleared in IRQSTA on the ADuC7024?

    If all bits within IRQSTA are cleared automatically when returning from IRQ_Handler(), then if a conditional method were used to handle the IRQ sources, such that all are not neccesarily handled in a single pass through the ISR then there could be a difference in non-latching IRQSIG interrupt sources (like the external interrupt pin you use as an example) and peripherals interrupts that latch a bit in IRQSIG, so that only unhandled (latched) interrupt sources with a bit still '1' in IRQSIG will cause a retrigger of the corresponding bit in IRQSTA.

    I see that the interrupt system for the ADuC7023 and ADuC7034 must be different from the ADuC7024 as for these parts it says:

    "IRQSTA/FIQSTA should be saved immediately upon entering the interrupt service routine (ISR) to ensure that all valid interrupt sources are serviced."

    Which I presume must mean the ISR must be styled as:

    IRQSTA_COPY = IRQSTA;

    if ((IRQSTA_COPY & TIMER_BIT) != 0)
    {
    }
    if ((IRQSTA_COPY & UART_BIT) != 0)
    {
    }
    if ((IRQSTA_COPY & ADC_BIT) != 0)
    {
    }

    :

    The ADuC7023 also says "FIQSTA is a read-only register that provides the current enabled FIQ source status (effectively a logic AND of the FIQSIG and FIQEN bits)", while the ADuC7034 says "IRQSTA provides the status of the IRQ source that is currently enabled (that is, a logic AND of the IRQSIG and IRQEN bits)".

  • 0
    •  Analog Employees 
    on May 1, 2014 3:03 PM

    (iv) Writing to ADCCON when a conversion is under way will cause the current conversion to stop and a new conversion to start.

    (v) Same as (iv)

    I'd like to make a correction to (v)

    I found that writing to ADCCP does in fact not restart the ADC. If I change ADCCP during the conversion phase, the next result I get is from the first channel, and if I change it during the aquisition phase the result I get is from the second channel. Also looking at the ADCBusy pin the timing doesn't change.

    One thing to note in the second case where the result is chagned during the aquisition phase is that the ADC aquires the first channel for some time and then the second channel, so the result will be some convoluted mix of both channels.

    This seems to be the case for ADuC702x parts and ADuC7023 and from talking to people SAR ADCs are normally like this.

    Regards,

    Alex