Strange behavior of GPIO

[jasonyeh]

Posted on January 18, 2009 at 09:03

Strange behavior of GPIO

[jasonyeh]

Posted on May 17, 2011 at 12:59

Hi,

I use STM32F101C8 controller to access TI's ADS8317 adc, I use 3 GPIO pin to connect to CS/DCLK/DOUT of ADS8 The MSB is retrieve from 7th rising edge, total 16-bit data. The signal from the scope shows that the lsb should be ''1'', but I always get ''0'', anybody can help me? My code of accessing the adc: // disable ISRs __disable_irq(); // drive NCS & DCLK low GPIO_ADC->BRR = ADC_NCS; GPIO_ADC->BRR = ADC_DCLK; bits = 23; rtv = 0; while(bits--) { rtv <<=1; GPIO_A->BSRR = ADC_DCLK; rtv |= (GPIO_ADC->IDR >>7)&0x1; GPIO_ADC->BRR = ADC_DCLK; } GPIO_ADC->BSRR = ADC_DCLK; GPIO_ADC->BSRR = ADC_NCS; __enable_irq(); the pin usage: ADC_NCS -> GPIOA.5 ADC_DCLK-> GPIOA.6 ADC_DOUT-> GPIO.7

http://p6.p.pixnet.net/albums/userpics/6/6/590966/4970aec081c1a.jpg

Code:

[LIST]

[relaxe]

Posted on May 17, 2011 at 12:59

If you vary the input signal, does the LSB varies a bit? or is it =stead= at LSB=1? Is it a communication problem, or simply an acquisition problem?

According to the ADS8317 datasheet, there can be a precision error of around 0.5bit, meaning a signal ''that rounds to lsb =0'' may ''round to lsb = 1''. -relaxe

[jj]

Posted on May 17, 2011 at 12:59

Since your scope clearly shows the LSB as high - the issue is not ''acquisition'' as the earlier poster suggested.

Pulled up/reviewed your ADC data sheet. Your scope trace shows a data value of 0xE93F. You did not say how much - if ''any'' - data you receive correctly. I've reviewed your code and cannot see what would corrupt ''only'' the lsb. It would be useful if we knew how much of the 0xE93F data (per your scope trace) is correct. It appears that even if you are 1 bit short - or 1 bit long - the lsb would still be ''1.'' We need to know how well the remainder of your data recovery function performed. At that time we can better revisit your lsb error - but I believe that lsb alone is ''not'' your issue. *** suddenly dawned on me - as the ''initial/confirming'' bit from the ADC(not part of your 16 bit conversion) is always a zero - is it possible that you are mis-processing your shifted/recovered data - mistakenly reading this initial bit - and that this is why you always read zero? [ This message was edited by: jj.sprague on 17-01-2009 01:22 ]

[jasonyeh]

Posted on May 17, 2011 at 12:59

Hi,

I had try to set bits=23 & 24, when using 23, the result is ''E93E'', the result of using 24 is ''D27E'', so I think the shift operation seems correct.

[jj]

Posted on May 17, 2011 at 12:59

Ok - as you correctly recover the first 15 bits of the 16 bit conversion it seems likely that your set-up or processing of the var ''rtc'' is the culprit. Post your relevant ''rtv'' set-up & processing code so we can examine...

[jasonyeh]

Posted on May 17, 2011 at 12:59

Hi jj.sprague,

you are right!!! I review my code and there is something wrong dump the result to usart, thanks.