No entendí tu pregunta.
Fuente de alimentación digital Buck-Boost con rectificación síncrona basada en STM32, código abierto
El código fuente está aquí
Todavía no entiendo qué es lo que quieres preguntar.
Hola blogger, te consulto: solo modifiqué el módulo de alimentación auxiliar, sustituyendo tu módulo reductor DCDC por un módulo NDP2355KC. Para el inductor de potencia usé el PSPMAA0605H-100M-ANP. El problema es que, cuando introduzco voltajes como 16V y quiero ajustar una salida de alrededor de 10V, el sistema se reinicia (cuando se alimenta por el puerto C) o produce un cortocircuito, entregando corriente máxima (cuando se alimenta con una fuente estabilizada). Cuando uso una fuente de alimentación de CC, la fuente entra en modo CC y la tensión de salida se mantiene alrededor de 6V, además del calentamiento excesivo del MOSFET en la placa. ¿Podrías analizar qué está ocurriendo? Gracias.
Verifica si hay un cortocircuito en el puerto de salida
Revisa tu diseño de PCB
La salida tampoco está en cortocircuito
La línea de muestreo parece no estar conectada, y el muestreo de corriente no utiliza un recorrido Kelvin
Fue que la resistencia se giró accidentalmente un poco. El PCB no tiene problemas. En cuanto a la muestra de corriente, efectivamente no me di cuenta de que debía usar la conexión de Kelvin. Gracias al bloguero por la recordatoria.
¿Cómo configuro este HRTIM para que dispare el muestreo del ADC en el punto central del período PWM? Intenté configurarlo, pero el tiempo de disparo no es correcto, ocurre mucho más tarde de lo que configuré. ¿Cómo puedo averiguar dónde está el problema?
Manda una captura de pantalla para ver cómo lo configuraste.
Solo usé C, D es para una futura expansión
En mis pruebas descubrí que el instante en que se invierte mi pin PC15 siempre se retrasa 2.5uS respecto al instante que configuré, a continuación mi función de prueba
// Función de callback
void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc)
{
// ADC1_2_IRQHandler();
if (hadc->Instance == ADC2)
{
GPIOC->ODR ^= GPIO_PIN_15;
Control_Loop_Update(); // Tu bucle de control de alta frecuencia
// GPIOC->ODR ^= GPIO_PIN_15;
}
else if (hadc->Instance == ADC1)
{
// GPIOC->ODR ^= GPIO_PIN_13;
// flag_adc1 = 1;
PID_V();
GPIOC->ODR ^= GPIO_PIN_13;
}
// HAL_GPIO_WritePin(GPIOB, GPIO_PIN_15, GPIO_PIN_RESET); // Poner a nivel bajo
}
No sé por qué el orden de esta captura de pantalla está desordenado 
Hermano, tu método de prueba en sí ya tiene un problema. Al hacer toggle en un pin IO dentro de HAL_ADC_ConvCpltCallback, lo que mides no es para nada el «tiempo de disparo», sino el «tiempo de muestreo del ADC + tiempo de conversión + latencia de respuesta a la interrupción + la enorme sobrecarga de comprobaciones de la HAL».
Entra en HAL_ADC_IRQHandler y mira el código fuente y lo entenderás. La HAL de ST comprueba un montón de estados de registros antes de llamar a este callback, así que perder 1~2 µs por el camino es de lo más normal. Además, en la captura de pantalla que pusiste el tiempo de muestreo configurado es de 6.5 ciclos, y la conversión requiere otros 12.5; ese tiempo es puro y duro.
Si quieres medir el punto de disparo real, configura directamente un pin de salida de comparación del temporizador y usa un osciloscopio para capturar la onda PWM y dicha salida. Si insistes en medirlo en la interrupción, desecha la HAL, busca directamente la entrada de interrupción del ADC en el archivo de inicio y haz toggle en el GPIO en la primera línea; verás que la latencia se reduce drásticamente al instante.
1 me gusta
Le he echado un vistazo a tu captura de CubeMX, te sugiero revisar los siguientes puntos sospechosos:
- Tu fuente de disparo del ADC está configurada como
Timer C Compare 3, y veo que en la configuración del Timer C estableciste Compare 3 en46080 / 4. Si tu período de PWM es 46080, ¿el punto central no debería ser/2? (A menos que estés utilizando el modo de alineación central, en cuyo caso hay que calcularlo específicamente). - El flanco de disparo del ADC que elegiste es
Trigger detection on the falling edge(disparo por flanco de bajada). ¿Confirmas que el evento de disparo generado por el HRTIM sea un flanco de bajada en la posición donde lo esperas? Normalmente se suele configurar por defecto con el flanco de subida. - Como comentaba el usuario de arriba, los 2.5uS son definitivamente sobrecarga de software. Con el G474 a 170 MHz de reloj, en 2.5uS se ejecutan aproximadamente 400 instrucciones, y todo se gasta en entrar a la interrupción, el apilado de registros y los condicionales IF de la HAL. Te recomiendo usar DMA: que el ADC al terminar de muestrear dispare el DMA directamente para mover los datos, en lugar de usar la interrupción del CPU para esperar.
1 me gusta
Sí, después lo volví a probar y noté que, al meterlo en la función ADC1_2_IRQHandler, casi no hay latencia.
Hola expertos, estoy en proceso de prueba y al principio funcionaba con normalidad (el «rizado» de salida era muy grande, a la misma frecuencia que la de conmutación pero amplificado, su frecuencia era muy alta, como se ve en la imagen). Luego añadí varios condensadores de salida, y al volver a alimentarlo, parece que todos los ADC del 32 se han estropeado; ahora los datos que miden los pines del ADC son siempre los mismos sin importar la entrada externa. ¿Cuál puede ser la causa de esto? Mi tensión de entrada es de 40 V, la salida configurada a 30 V y la carga es de 20R. Quería preguntar si después del módulo de prueba hace falta añadir un componente para proteger los pines del 32. Si es así, ¿hay alguna recomendación? ¡Gracias, expertos!
No entiendo qué estás diciendo, ¿es esta mi placa de código abierto?
La topología es la misma, solo que esta la he dibujado yo mismo.
Mis preguntas son:
-
En la gráfica de medición del componente de CA de la salida, ¿por qué aparece este pico tan alto? Aparece 4 veces dentro de un ciclo de conmutación, ¿cómo puedo eliminar este efecto?
-
Durante las pruebas de la placa, toda la sección del ADC del STM32 se averió. No sé por qué se podría haber dañado la parte del ADC; tengo un filtro RC paso bajo antes del pin del ADC y, aun así, el pin se quemó. ¿Cuál podría ser la causa de esto? Antes pregunté sospechando que el pin del ADC estaba dañado, y ahora estoy prácticamente seguro de que realmente se ha estropeado. (Supongo que debido a que el pico del componente de CA en la gráfica anterior es demasiado alto, el pin del ADC del STM32 se dañó, no sé si mi suposición sea correcta). Ya he quemado dos microcontroladores, ambos por daños en los pines del ADC, pero no encuentro la causa.
-
Si quiero darle una protección adicional al pin del ADC del STM32 para que la entrada del ADC se mantenga entre 0 y 3.3, ¿hay algún método o dispositivo que funcione bien?