Stupid problem with ADC sampling

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Stupid problem with ADC sampling

1,469 Views
lc_hc
Contributor I

Hello there,


I feel really like a noob, since I didn´t manage to get my HCS08DZ60 ADC running. I´m sure everythings set well, but

in debugging mode via PE micro dongle the COCO flag is never set. Here´s my Code. It would be great if someone can help me with that. Thank you guys in advance.


My init code:

 


void Adc_Init(void)
{

    /* ADCSC1: COCO=0,AIEN=0,ADCO=0,ADCH4=0,ADCH3=1,ADCH2=1,ADCH1=1,ADCH0=1 */
    /*setReg8(ADCSC1, 0x1F);               /* Disable the module */
    ADCSC1 = 0x1F;
    
    /* ADCSC2: ADACT=0,ADTRG=0,ACFE=0,ACFGT=0,??=0,??=0,??=0,??=0 */
    /*setReg8(ADCSC2, 0x00);               /* Disable HW trigger and autocompare */
    ADCSC2 = 0x00;
    
    /* ADCCFD: ADLCP=0,ADIV_h=,ADIV_l=,ADLSMP=0,MODE_h=,MODE_l=,ADICLK_h=,ADICLK_l= */
    /*setReg8(ADCCFG, 0x48);               /* Set prescaler bits */
    ADCCFG = 0x28;
    
    
    if( adc_driverStatus != STOP ) /* Set ADC to STOP mode if not set */
    {
        adc_driverStatus = STOP;
    }
    
    adc_driverInitialized = TRUE;    /* Set driver init status */
}

 

and here´s my polling function: 


Adc_ResultType Adc_Measure( Adc_ChannelType channel )
{
    volatile Adc_ResultType result = 0;

    unsigned int i; /* counter for ADC sample cycles */

   
    /* sampe ADC channels */
    for( i = 0; i < ADC_SAMPLE_CYCLES; i++)
    {
        ADCSC1 = channel;


        /* wait while conversion is in progress */
        while ( !(ADCSC1 & (1<<7) ) )
        {
            asm("nop");
        }

        /* make sum of ADC Register values */
        result += ( (ADCRH << 8) + ADCRL );
       
    }

   
    
    Adc_Stop();    /* stop ADC conversion by setting ADCSC1 = 0x1F */
    

    /* divide by number of samples for "low pass" filtering */
    return ( result >> ( ADC_SAMPLE_CYCLES >> 2 ) );
}

 

I´m really going crazy, since the ADCSC1 in hiwave shows a HI COCO bit when ADCSC1 is set with 0x01, but shows a LO COCO bit in the next step. ADACT flag in ADCSC2 never becomes 1.

 

Thank you guys.

 

Greets

 

Simon

Labels (1)
0 Kudos
7 Replies

567 Views
bigmac
Specialist III

Hello Simon,

 

Further to Peg's response, the COCO flag is cleared by a read of ADCRL, whether by the program or the debugger.

 

Regards,

Mac

 

0 Kudos

567 Views
lc_hc
Contributor I

Thank you for responding,

 

does this mean, it is not possible to debug the ADC due to reset of COCO by the debugger read ?
I do not even see a ADACT flag in ADCSC2 register, can you confirm, my code seems to be correct ?

Thank you guy again.

Best regards,

Simon

0 Kudos

567 Views
peg
Senior Contributor IV

Hi Simon,

Well it does mean that if you are going to monitor the ADCSC1 register so you can see the COCO bit, DO NOT also monitor ADCRL. This sort of thing happens with many S08 status bits.

ADACT is only high for a very short time. What is the ADC clock rate?

If you stop monitoring does it work?

 

0 Kudos

567 Views
lc_hc
Contributor I

Hi,

 

I think, I got it. But how can I NOT monitor the ADCRL Register ?

I call the conversio function from an applicatio task. If I set a breakpoint at the call of ADC conversion in the application task, the programm is running trough the code until it reaches the breakpoint again. If I step through the code from the adc conversion call by single step into the conversion function, it seems that a endless loop is generated by waiting until COCO is 1.

Does that describe the phenomenon ?

0 Kudos

567 Views
bigmac
Specialist III

Hello,

 

The solution is to simply not single step the code through the critical part of the function.  Set the break point to the line following the COCO flag wait loop.  The symptoms you describe fit the case of the debugger clearing the flag prior to the test of the flag state.

 

Regards,

Mac

 

0 Kudos

567 Views
peg
Senior Contributor IV

Hello,

 

If you are displaying the contents of the ADCRL register in the debugger the debugger will be polling the BDM for the value. The BDM will in turn be making internal accesses to that register. Reads by the application and the BDM are no different as far as the flag resetting mechanism is concerned. When you are stepping through these reads are being made prior to the application's COCO test and so when the application gets to that point it waits forever as the bit is already reset. Depending on settings within your debugger it is probably only making these reads when the processor is halted and so under a run condition no polling occurs and the code runs as expected. It is also possible that it just gets it done in between reads most of the time. So the situation you describe does fit what could happen as a result of monitoring ADCRL. As you have not specified what debugger you are running I do not know how to help you there.

0 Kudos

567 Views
peg
Senior Contributor IV

Hello,

 

Your not falling into the trap of monitoring registers in the debugger that once read, reset the flag in question. Are you?

0 Kudos