TODOPIC
Otros Microcontroladores / Dispositivos programables => Microcontroladores ARM => Mensaje iniciado por: fuente en 03 de Febrero de 2018, 16:52:21
-
Hola a todos.
Estoy haciendo pruebas con el ADC de un STM32F103C8 y estoy viendo que cuando pongo la entrada del ADC (cualquiera de sus entradas) a GND, la lectura que obtengo oscila entre 0 y 20, mientras que si la pongo a 3,3V oscila entre 4070 y 4095.
He hecho la misma prueba con un tm4C123, con la placa TivaC launchpad de TI y cuando pongo la entrada del ADC a GND, se va a 0, sin variación alguna, y cuando la pongo a 3,3V, se va a 4095, también sin variación.
Al STM le hago la calibración al arrancar, pero aún así me da las variaciones que he comentado antes. También he probado a variar los tiempos de muestreo, pero sigue igual. También he probado a alimentarlo con baterías por si fuera culpa del rizado de la fuente de alimentación, pero sigue igual.
¿Se puede corregir esto o es que el ADC del STM no es estable?
-
El unico "error" catalogado en el chip sobre el ADC es este:
2.1 Voltage glitch on ADC input 0
Description
A low-amplitude voltage glitch may be generated (on ADC input 0) on the PA0 pin, when the ADC is converting with injection trigger. It is generated by internal coupling and synchronized to the beginning and the end of the injection sequence, whatever the channel(s) to be converted. The glitch amplitude is less than 150 mV with a typical duration of 10 ns (measured with the I/O configured as high-impedance input and left unconnected). If PA0 is used as a digital output, this has no influence on the signal. If PA0 is used has a digital input, it will not be detected as a spurious transition, providing that PA0 is driven with an impedance lower than 5 kΩ. This glitch does not have any influence on the remaining port A pin or on the ADC conversion injection results, in single ADC configuration. When using the ADC in dual mode with injection trigger, and in order to avoid any side effect, it is advised to distribute the analog channels so that Channel 0 is configured as an injected channel.
Workaround
None.
Pero no se si sea eso lo que te afecta, podes crear un codigo muy pequeño que lo ponga a prueba?
-
Muchas gracias por contestar KILLERJC.
Esa nota ya la había visto, pero en teoría solo afecta al primer canal del ADC cuando estas inyectando la lectura de otro.
He probado en varias entradas y pasa lo mismo. La placa que estoy usando es una comprada en banggood, es muy simple y no parece que esté mal.
Luego pondré el código que estoy usando para probarlo por si veis algo que se me esté escapado.
-
Aquí pongo los archivos main.c y adc.c
El proyecto está generado con el STM32CubeMX.
La idea es leer 10 veces cada canal por DMA. Una vez leido, se para el ADC hasta la próxima lectura (5 segundos con un Delay, más tarde lo haría mediante interrupciones).
pongo también una captura de pantalla de una de las lecturas. Cada columna corresponde a un canal. Los tres primeros canales están conectados a GND y los tres siguientes a 3,3V.
- Tienes que ingresar para ver archivos adjuntos -
- Tienes que ingresar para ver archivos adjuntos -
- Tienes que ingresar para ver archivos adjuntos -
-
Acabo de probar con una placa Arduino DUE y el ADC va bien. Con la entrada conectada a GND la lectura es siempre 0 y con la entrada conectada a 3,3V es de 4094 estable.
También he probado con la placa del STM32F030 y en este tengo el mismo problema. ¿Alguien puede hacer alguna prueba del ADC con estos u otros micros de ST?
-
La verdad es que en el codigo que pasaste no tiene nada, solo que activa el sampleo, la configuracion del ADC no esta. Aun asi... ese error es rarisimo, tengo una placa ST que me lo facilito elgarbe, cualquier cosa pruebo alli si es que funciona igual o no. Lo que si estos dias estoy bastante ocupado y tengo trabajo para hacer que ya llevo retrasado.
-
Hola KILLERJC.
Muchísimas gracias por la molestia que te estás tomando, y no corre ninguna prisa, es por hobby y por supuesto que el trabajo es lo primero (después de la familia, claro).
La configuración del ADC sí que está, pero en el post se había quedado algo escondida. Lo he reorganizado para que se vea algo mejor. Es el archivo adc.c que genera el STM32CubeMX.
La verdad es que me sorprende que todos los demás micros, tanto ARM como pic o atmel (también probé en un arduino uno) sean bastante estables en el ADC y estos dos STM con los que he probado tengan este problema. Supongo que estaré configurando algo mal o que algo se me está pasando por alto, pero no doy con ello.
-
¿Estas utilizando una tarjeta de desarrollo o una tarjeta elaborada por ti?
¿puede que el pin tenga alguna señal cercana que le haga interferencia?
Si estas utilizando un IDE basado en Eclipse se pueden exportar los proyectos (Archivo -> Exportar) para poder compartirlos, si se puede claro :). No tengo ese mismo micro que estas utilizando pero podría ser más fácil para Killer reproducir el problema que tienes.
Saludos
-
Prueba con un código fuente que ya esté depurado y comprobado que funciona. Aqui tienes ejemplos de uso del ADC, con y sin DMA, para ese micro.
https://github.com/avislab/STM32F103?files=1
No he usado nunca ese micro, pero el problema tiene pinta de ser algo relacionado con configuración de voltajes de referencia.
-
Y yo lo que poseo es un STM32F4 en la Nucleo, y un STM32F030 en otra plaquita. Apenas pueda, Primero lo pruebo en el F4 y si no hay problema lo pruebo en el F0
-
Muchísimas gracias a todos.
Las placas en las que estoy probando son estas:
https://www.banggood.com/STM32F103C8T6-ARM-STM32-Mini-System-Development-Board-STM32F103-Core-Board-p-1207605.html?rmmds=search&cur_warehouse=CN
https://www.banggood.com/STM32F030F4P6-Small-Systems-Development-Board-CORTEX-M0-Core-32bit-Mini-System-p-1207600.html?rmmds=search&cur_warehouse=CN
Como IDE estoy utilizando CodeBlocks. No he adjuntado el proyecto entero porque el STM32CubeMX copia todas las librerías y son muchos archivos, pero no tengo ningún inconveniente en meterlo en un zip y subirlo.
Lo haré esta noche.
En cuanto a los voltajes de referencia que comenta planeta9999, el 32F103 no tiene referencia interna y utiliza directamente VDD. Creo que el 32F030 también, pero no lo puedo confirmar ahora mismo.
Las placas son bastante simples, y no parece haber ninguna pista cerca de las de las entradas analógicas que puedan meter ruido. Las he probado a alimentar desde el USB del pc y con una batería, pero todo sigue igual.
-
Hola de nuevo.
Este es el proyecto de CodeBlocks. He tenido que quitar la carpeta de Drivers (todas las librerías HAL y CMSIS) para no sobrepasar el tamaño máximo que deja subir.
Muchísimas gracais a todos.
- Tienes que ingresar para ver archivos adjuntos -
-
Hola,
Bajé el zip y revisé el main, no vi nada que pueda introducir el error de lectura que haz visto, falta ver que puede encontrar Killer :).
Cambie un poco el main, la funcionalidad sigue siendo la misma pero noté que inicializabas los elementos del array DMA_array con un for, eso se puede hacer a la hora de declararlo con:
uint32_t DMA_array[60] = {0}; // <- Con esto todos los elementos del array se inicializan a 0
Algo parecido con la variable intADCListo, como a utilizas como flag la podrías declarar de tipo bool, incluyendo el header <stdbool.h>, igual la puedes inicializar a la hora de declararla:
volatile bool intADCListo = false;
El main:
#include "main.h"
#include "stm32f1xx_hal.h"
#include "adc.h"
#include "can.h"
#include "dma.h"
#include "usart.h"
#include "gpio.h"
/* USER CODE BEGIN Includes */
#include <string.h>
#include <stdbool.h>
/* USER CODE END Includes */
/* Private variables ---------------------------------------------------------*/
/* USER CODE BEGIN PV */
/* Private variables ---------------------------------------------------------*/
volatile bool intADCListo = false;
uint32_t ADC_raw[60] = {0}; // inicializa todos los elementos del array a 0
/* USER CODE END PV */
/* Private function prototypes -----------------------------------------------*/
void SystemClock_Config(void);
/* USER CODE BEGIN PFP */
/* Private function prototypes -----------------------------------------------*/
/* USER CODE END PFP */
/* USER CODE BEGIN 0 */
void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc) {
if(hadc->Instance == ADC1) {
HAL_ADC_Stop_DMA(&hadc1);
intADCListo = true;
}
}
/* USER CODE END 0 */
int main(void)
{
/* USER CODE BEGIN 1 */
char buffer[100];
int len;
/* USER CODE END 1 */
/* MCU Configuration----------------------------------------------------------*/
/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
HAL_Init();
/* USER CODE BEGIN Init */
/* USER CODE END Init */
/* Configure the system clock */
SystemClock_Config();
/* USER CODE BEGIN SysInit */
/* USER CODE END SysInit */
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_DMA_Init();
MX_ADC1_Init();
MX_USART1_UART_Init();
MX_CAN_Init();
/* USER CODE BEGIN 2 */
while(HAL_ADCEx_Calibration_Start(&hadc1) != HAL_OK); // calibrate AD convertor
//HAL_ADCEx_Calibration_Start(&hadc1);
HAL_GPIO_WritePin(LED_GPIO_Port,LED_Pin,GPIO_PIN_RESET);
HAL_ADC_Start_DMA(&hadc1, (uint32_t*) ADC_raw, 60);
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
for(uint8_t i = 0;i < 10; i++) {
HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); //Toggle LED
HAL_Delay(1000);
}
while (1) {
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
HAL_Delay(5000); //Delay del blink
HAL_GPIO_TogglePin(LED_GPIO_Port,LED_Pin);
if (true == intADCListo) {
len = sprintf(buffer, "%c[2J\r\n", 27); //Limpia la pantalla.
HAL_UART_Transmit(&huart1, buffer, len, 10);
len = sprintf(buffer, "%c[H\r\n",27); //cursor a la esquina superior izquierda.
HAL_UART_Transmit(&huart1, buffer, len, 10);
for(uint8_t j = 0; j < 10; j++){
len = sprintf(buffer, "%lu %lu %lu %lu %lu %lu\r\n", ADC_raw[0+6*j],
ADC_raw[1+6*j], ADC_raw[2+6*j], ADC_raw[3+6*j],
ADC_raw[4+6*j], ADC_raw[5+6*j]);
HAL_UART_Transmit(&huart1, buffer, len, 1000);
}
intADCListo = false;
HAL_ADC_Start_DMA(&hadc1, (uint32_t*) ADC_raw, 60);
}
}
/* USER CODE END 3 */
}
Con respecto al error que ves, según mis cálculos el error de 20 cuentas que ves equivale a ~64mV.
Suponiendo que la referencia sea 3.3V y el ADC sea de 10bits:
2^10 (o 1024) cuentas = 3.3V
1 cuenta = 3.2mV
20 cuentas = 64.4mV
igual se le puede atribuir un poco al ruteo de la placa, o podrías revisar cambiando el sample time del adc, segun el adc.c creo esta configurado a 7 ciclos del reloj.
-
En el siguiente documento se muestran los errores del ADC.
http://www.st.com/content/ccc/resource/technical/document/application_note/group0/3f/4c/a4/82/bd/63/4e/92/CD00211314/files/CD00211314.pdf/jcr:content/translations/en.CD00211314.pdf
Tengo la misma tarjeta, y pues no creo que le metan componentes de calidad y quien sabe que tan bien esté diseñado el PCB, por ejemplo, en una de las tarjetas que tengo, el pin de 3.3V da 3.24V y de los 3 pines de GND sólo uno funciona, así que no espero nada bueno de ella, en cuestión de que obtenga valores estables, pero lo que si puedes hacer es incrementar ciertos valores de configuración para por lo menos reducir algunos de los errores.
Por ejemplo, de la hoja de datos, tenemos que
2 x 12-bit, 1 μs A/D
Es decir que la conversión de Análogo a Digital le toma 1us. Si tomamos en cuenta esa valor y además sabemos que, en este caso tanto ADC1 y ADC2 están conectados a un reloj de 12Mhz como se ve en la siguiente imagen. Entonces para obtener una conversión requiere de almenos 12 ciclos de reloj.
(https://i.imgur.com/EG7UKXz.png)
El valor con el que lo configuras es de 7.5 ciclos, de ahí que algunas o todas las lecturas pueden resultar más inestables de lo que esperarías normalmente ya que no le permites al ADC terminar con la conversión (0.625us). En las imágenes siguientes podrás constatar el error que se presenta al leer tres entradas (ADC_IN0 en PA0, Temperatura, Vrefint), cuando coloco PA0 a 3.3V (aunque el aparatito sólo me entrega 3.24V) y a GND.
(https://i.imgur.com/poXs8Rd.png)
(https://i.imgur.com/bcI8BbC.png)
En cambio si se que requiere 12 ciclos, el valor de configuración más cercano que sea superior es 13.5 ciclos y el resultado se puede ver en las siguientes imágenes.
(https://i.imgur.com/lxAUvgU.png)
(https://i.imgur.com/EP4PvGQ.png)
El mayor error que se aprecia en las lecturas del VTemp y Vref, cuando se cambia de 3.3 a GND.
Cuando se aumenta 28.5 ciclos
(https://i.imgur.com/y2epNul.png)
(https://i.imgur.com/vMH12DG.png)
71.5 ciclos
(https://i.imgur.com/mrYr1SH.png)
(https://i.imgur.com/kZJm4d9.png)
239.5 ciclos
(https://i.imgur.com/JaCZX6G.png)
(https://i.imgur.com/FykSxtG.png)
Esta es la configuración del ADC con el que hice las pruebas.
hadc1.Instance = ADC1;
hadc1.Init.ScanConvMode = ADC_SCAN_ENABLE;
hadc1.Init.ContinuousConvMode = DISABLE;
hadc1.Init.DiscontinuousConvMode = DISABLE;
hadc1.Init.ExternalTrigConv = ADC_SOFTWARE_START;
hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT;
hadc1.Init.NbrOfConversion = 3;
sConfig.SamplingTime = ADC_SAMPLETIME_7CYCLES_5;
//sConfig.SamplingTime = ADC_SAMPLETIME_13CYCLES_5;
//sConfig.SamplingTime = ADC_SAMPLETIME_28CYCLES_5;
//sConfig.SamplingTime = ADC_SAMPLETIME_71CYCLES_5;
//sConfig.SamplingTime = ADC_SAMPLETIME_239CYCLES_5;
En la configuración del DMA lo coloqué normal, en lugar de circular. Y las lecturas las realizo a través de un Timer.
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
if(htim->Instance == htim3.Instance)
{
HAL_ADC_Start_DMA(&hadc1, g_ADCBuffer, 9);
}
}
void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *AdcHandle)
{
sprintf(buffer,"%i %i %i %i %i %i %i %i %i\n", g_ADCBuffer[0],
g_ADCBuffer[3],
g_ADCBuffer[6],
g_ADCBuffer[1],
g_ADCBuffer[4],
g_ADCBuffer[7],
g_ADCBuffer[2],
g_ADCBuffer[5],
g_ADCBuffer[8]);
CDC_Transmit_FS((uint8_t *)&buffer,strlen(buffer));
}
-
Intentaré repasar las soldaduras del micro a ver si mejora.
En cuanto al tiempo de muestreo, en el proyecto quedó como 7,5 ciclos, pero estuve haciendo pruebas con otros tiempos de muestreo sin ver mejoras.
Lo que no he hecho y tengo que probar es a jugar con el preescaler de la velocidad del ADC y del bus.
Lo que comentas de la tensión de 3,24 creo que no importaría mucho, ya que en este micro la referencia es precisamente la tensión de alimentación, y si le estoy aplicando la tensión de alimentación, que es la referencia, a la entrada del ADC, éste debería devolver el valor 4095, independientemente de que se alimente a 3,3 ó 3,24. Y lo mismo cuando se pone la entrada a GND. La salida del ADC en este caso debería ser 0.
-
¿ Y no te resultaría mejor, para descartar problemas de hardware, probar con el código que te dí, que está probado que funciona ?, https://github.com/avislab/STM32F103?files=1 , ahí tienes ejemplos listos para usar el ADC de ese micro, con y sin DMA.
Si este te funciona, entonces es un problema de software, compáralo con el tuyo y busca las diferencias, o directamente parte de este código, añadiendo tus rutinas. Y si te aparece el mismo problema, ya sabes que es de hardware y no andas perdiendo el tiempo, cambiando cosas en el software, que no van a resolver nada.
No se, es una sugerencia, yo lo haría así, para centrarme en el problema y no andar dando tumbos sin saber por donde anda la cosa.
-
Sí, tengo pendiente hacerlo, pero no me he podido poner con ello todavía.
Como dije, es por hobby, y ya sabéis lo que pasa con estas cosas...
-
Si lees el archivo que enlacé, la mayoría de los errores son esperados pero muestran formas de como disminuir sus efectos tanto en hardware como en software.
La primera tarjeta con la que probé, de antemano se que está mal, pero la siguiente es el resultado de una prueba con otra tarjeta del mismo tipo con 13.5 ciclos (ADC_IN0, V_TEMP, VREFINT)
4095 4094 4094 1712 1715 1715 1399 1396 1395
4095 4095 4095 1713 1714 1716 1398 1396 1396
4095 4095 4095 1713 1715 1715 1400 1396 1395
4095 4095 4095 1715 1715 1715 1394 1394 1396
4095 4092 4094 1714 1715 1715 1396 1397 1394
4095 4094 4091 1715 1715 1714 1395 1396 1396
4095 4095 4094 1713 1715 1716 1399 1399 1398
4095 4095 4095 1714 1715 1713 1398 1396 1396
4095 4095 4095 1714 1715 1718 1400 1395 1393
4095 4094 4094 1714 1714 1716 1397 1395 1396
4090 4095 4095 1714 1715 1715 1396 1395 1396
0 0 0 1766 1769 1766 1382 1381 1379
0 0 0 1766 1766 1767 1382 1381 1384
0 0 0 1765 1766 1768 1380 1382 1380
0 0 0 1767 1768 1767 1379 1380 1381
0 0 0 1765 1766 1769 1382 1379 1377
0 0 0 1765 1768 1768 1379 1382 1379
0 0 0 1767 1768 1765 1380 1381 1382
1 0 0 1768 1767 1766 1381 1381 1380
0 0 0 1766 1767 1767 1379 1385 1380
0 0 0 1767 1768 1768 1383 1380 1380
3 0 0 1766 1768 1767 1382 1381 1379
Y no he cambiado nada del código de prueba.
Volví a leer las hojas de datos y el tiempo total de conversión se calcula
Tconv <= Sampling Time + 12.5 cycles.
Así si se elije 13.5 ciclos Tconv sería de 2.16us, pero en la misma hoja de datos hace referencia a los tiempos en los cuales está garantizada una lectura precisa. La lectura de la temperatura la garantizan con un tiempo de muestreo de 17.1us, así que la muevo al final y la configuro con 239.5 ciclos. De igual forma incremento el tiempo de muestreo a 239.5 ciclos para la lectura de VREFINT, ya que también su lectura está garantizada con un tiempo de muestreo de 17.1us.
(https://i.imgur.com/oZvZcfo.png)
(https://i.imgur.com/iLI2jJt.png)
(ADC_IN0, VREFINT, V_TEMP)
4095 4095 4095 1489 1489 1490 1757 1757 1757
4095 4095 4095 1489 1488 1489 1759 1757 1757
4095 4095 4095 1490 1488 1489 1753 1759 1757
4095 4095 4095 1489 1488 1489 1757 1757 1758
4095 4095 4095 1490 1489 1490 1755 1759 1759
4095 4095 4095 1491 1488 1487 1759 1757 1757
4095 4094 4095 1489 1489 1492 1757 1758 1756
4095 4095 4095 1492 1489 1489 1758 1760 1757
4095 4095 4095 1488 1489 1491 1757 1757 1757
4095 4095 4095 1492 1490 1489 1757 1757 1761
4095 4095 4095 1489 1488 1491 1759 1759 1759
0 0 0 1493 1494 1495 1760 1756 1757
0 0 0 1494 1493 1493 1759 1756 1757
0 0 0 1492 1492 1494 1758 1757 1757
0 0 0 1494 1492 1492 1758 1753 1757
0 0 0 1493 1492 1496 1759 1758 1757
0 0 1 1494 1493 1491 1757 1758 1757
0 0 0 1493 1490 1493 1757 1757 1756
0 0 0 1491 1493 1493 1758 1758 1756
0 0 0 1492 1493 1492 1757 1757 1756
0 0 0 1493 1495 1493 1757 1757 1755
0 0 0 1493 1493 1492 1757 1759 1757
Y no sólo se estabilizaron las lecturas, sino que obtengo valores dentro de lo que la hoja de datos me dice.
Por ejemplo VREFINT puede tener valores entre, 1.16 a 1.26, siendo 1.20 el típico. Sin considerar la hoja de datos, lo que en apariencia leía era alrededor de 1V, pero con estos resultados está alrededor de 1.18V que está dentro de los parámetros.
Adjunto el .hex y el .bin por si lo quieres probar en tu placa. Para ver las lecturas conectalo por USB y lo va a reconocer como puerto serie (115200 8 bits, 1 bit de stop sin paridad).
- Tienes que ingresar para ver archivos adjuntos -
-
Pues entonces debe ser cosa de la placa.
planeta9999, acabo de probar con los ejemplos que pusiste.
Pongo los archivos de las lecturas que he obtenido, uno con A1 puesto a 3,3V y otro con A1 puesto a GND.
Al poner A1 a GND se obtienen valores que llegan hasta 13. Aquí algo mejora. Pero cuando pongo A1 a 3,3V empeora.
- Tienes que ingresar para ver archivos adjuntos -
- Tienes que ingresar para ver archivos adjuntos -
tsk, he vuelto a probar subiendo el tiempo de muestreo al máximo, 239,5 ciclos, y en otra prueba además he reducido la velocidad del ADC poniendo el prescaler a 8, con lo que la frecuencia del ADC queda en 9MHz. No he hecho captura de las salidas, pero no ha mejorado nada.
Queda echarle un repaso a la placa...
-
Bueno despues de probar no logro hacer
funcionar el DMA xD jeje
Correccion, no me funciona el callback... no me lo ejecuta....
EDIT:
Finalmente consegui ver que .... llama a todos lso callback ( half, complete y error ), lo peor de todo es que me llama al de error tambien :P.
Logre que funcionara. Y acabo de ver que tiene el mismo efecto que indico tsk
Ponerlo a GND, dependiendo de la entrada incluso con el mayor tiempo de sampling implica un cambio que va desde 1 a 4 en algunos canales, y de 1 a 2 en otros.
Ponerlo a 3V3, tambien modifica un poco la lectura dejandolo entre 4094 y 4095.
-
Pues entonces confirmado, debe ser cosa de la placa que estoy utilizando.
El caso es que después de repasarla sigue igual.
Muchísimas gracias a todos por vuestra ayuda.
-
Hola,
Encontré una AppNote sobre el ADC en los STM32 (al parecer todos traen el mismo ADC SAR), la puedes ver acá: AN2834 - How to get the best ADC accuracy in STM32 microcontrollers (http://www.st.com/content/ccc/resource/technical/document/application_note/group0/3f/4c/a4/82/bd/63/4e/92/CD00211314/files/CD00211314.pdf/jcr:content/translations/en.CD00211314.pdf).
Tiene una lista de los errores más comunes:
- Errores del ADC:
- Offset Error
- Gain Error
- Differential linearity error
- Integral linearity error
- Total Unadjusted error
- Errores debido al ambiente:
- Reference voltage noise
- Reference voltage/ power supply regulation
- External reference voltage parameters
- Analog input signal noise
- ADC dynamic range bad match for maximum input signal amplitude
- Effect of the analog signal source resistance
- Effect of source capacitance and parasitic capacitance of the PCB
- Injection current effect
- Temperature influence
- I/O pin crosstalk
- EMI-induces noise
El error que comentaba era el de la PCB, que es uno de los pocos que enumeran, también trae como mejorar la precisión del ADC (por software y hardware).
Saludos