Qué puede provocar que un PIC se reinicie?
jugator EChMotor#140
El tema es que lo tengo montado para controlar un pequeño robot. Algo
sencillo, un sensor de colisión, dos sensores de temperatura sobre I2C, dos
motores de contínua con un L298, comunicación por RS232 y poca cosa más.
Hasta ahora funcionaba bien (o eso creía). El tema es que ahora le estoy
haciendo que su comportamiento lo marque una máquina de estados finitos
(FSM), y he visto que cada tanto el PIC se reinicia (iba a decir que sólo,
pero no, si se reinicia es que hay un fallo de diseño en el circuito, en la
programación o yo qué sé), por lo que a tomar la FSM.
Por cierto, los reinicios son aleatorios, no pasan cada un cierto tiempo
determinado, y suceden en dos placas diferentes en diseño físico
(distribución de elementos y pistas) pero iguales en diseño lógico.
La pregunta es, qué puede provocar que un PIC se reinicie?
Miguel Gimenez
El motivo más frecuente es ruido eléctrico en los pines. Si comparten
fuente de alimentación el PIC y el motor, se produce ruido y saltos de
tensión que pueden activar el circuito de brown-out o provocar cambios
aleatorios en el estado de la CPU (por ejemplo, cambios del PC). Quítale
los motores o aliméntalos de una fuente secundaria para ver si
desaparecen los reinicios. También te pueden ocurrir si la corriente del
motor comparte camino con la del micro (trazado incorrecto), entonces no
se soluciona con dos fuentes sino con un retrazado.
--
Saludos
Miguel Giménez
jugator EChMotor#140
news:fuhqtk$3v2$1...@aioe.org...
>
> El motivo más frecuente es ruido eléctrico en los pines. Si comparten
> fuente de alimentación el PIC y el motor, se produce ruido y saltos de
> tensión que pueden activar el circuito de brown-out o provocar cambios
> aleatorios en el estado de la CPU (por ejemplo, cambios del PC). Quítale
> los motores o aliméntalos de una fuente secundaria para ver si desaparecen
> los reinicios. También te pueden ocurrir si la corriente del motor
> comparte camino con la del micro (trazado incorrecto), entonces no se
> soluciona con dos fuentes sino con un retrazado.
>
todo el sistema está alimentado por una pila de 9V. El PIC a través de un
7805 (5V); y el L298 tiene Vss conectado también a la salida del 7805, Vs
directamente a la pila de 9V y GND al negativo de la pila, que es común
también para el PIC.
Si cambio la pila por un alimentador externo enchufado a la red sigue
pasando.
Lo acabo de probar simplemente desconectando los motores. También ha llegado
a reiniciarse, y me aventuraría a decir que ha tardado bastante más en
hacerlo (aunque como es bastante aleatorio, no es seguro que así haya sido).
Miraré de separar circuitos de alimentación a ver qué ocurre.
Gracias
Miguel Gimenez
un cortocircuito de unas décimas de us cada vez que cambie de estado,
que provocará un salto de tensión (primero hacia abajo y después hacia
arriba) en la fuente y llegará directamente al micro (los 7805 no
responden demasiado bién a escalones). Añade (o aumenta) los tiempos
muertos y pon un condensador de 100 nF directamente en los bornes de
alimentación del L298.
--
Saludos
Miguel Giménez
Pepitof
siempre.
1º. Problema software. Como el reseteo es aleatorio, y suponiendo que el
programa lo has escrito en C, habrá que suponer que no es un timer contando
sin control, ni un salto a la página incorrecta, ni nada parecido, pero sí
podría ser por ejemplo que hayas configurado una patilla de reset y no la
hayas conectado. En ese caso, cuando reciba un pico de ruido suficientemente
grande (por radio), reseteará. También podría pasar algo parecido si tienes
un timer configurado por error con un clock externo.
2º. Problema hardware. Lo que te han dicho, ruido en la alimentación, es la
causa más común. La solución, separar alimentaciones de potencia y lógica,
sobredimensionar condensadores de filtro, añadir un condensadore de filtro
de 100nF a la alimentación del PIC, lo más cerca posible de él, asegurar que
las pistas de alimentación y masa están correctamente dimensionadas y
trazadas, y que no sean compartidas por el circuito de potencia y el lógico.
Luego ya podría haber problemas más sutiles, como un acoplamiento incorrecto
entre el PIC y otros chips (una resistencia en cada puerto utilizado que
limite la corriente máxima a 15mA puede hacer milagros).
Otro problema típico con control de motores mediante puentes H es no dejar
tiempo suficiente para la conmutación en cada rama de la H, con lo que
puedes tener corrientes instantáneas muy altas, cercanas a cortocircuito,
que echen abajo la alimentación (esto además seguiría pasando aunque
quitaras los motores).
En fin, ya nos dirás.
--
Saludos de Jose Manuel Garcia
jose...@terra.es
http://213.97.130.124
"jugator EChMotor#140" <jug...@gmail.com> escribió en el mensaje
news:fuhrvc$in0$1...@localhost.localdomain...
jugator EChMotor#140
>
> ¿Estás dejando tiempos muertos al conmutar el L298? Si no lo haces habrá
> un cortocircuito de unas décimas de us cada vez que cambie de estado, que
> provocará un salto de tensión (primero hacia abajo y después hacia arriba)
> en la fuente y llegará directamente al micro (los 7805 no responden
> demasiado bién a escalones). Añade (o aumenta) los tiempos muertos y pon
> un condensador de 100 nF directamente en los bornes de alimentación del
> L298.
>
pues no dejo tiempos muertos, no. Miraré de ponerlos ahora. El condensador
sí que está puesto.
Muchas gracias
jugator EChMotor#140
news:673c4sF...@mid.individual.net...
> Pues si quitando motores sigue reseteándose, la respuesta viene a ser la
> de
> siempre.
>
> 1º. Problema software. Como el reseteo es aleatorio, y suponiendo que el
> programa lo has escrito en C, habrá que suponer que no es un timer
> contando
> sin control, ni un salto a la página incorrecta, ni nada parecido, pero sí
> podría ser por ejemplo que hayas configurado una patilla de reset y no la
> hayas conectado. En ese caso, cuando reciba un pico de ruido
> suficientemente
> grande (por radio), reseteará. También podría pasar algo parecido si
> tienes
> un timer configurado por error con un clock externo.
>
me repasaré a fondo el código, ya que estoy reutilizando algo que alguien
creó en su día
> 2º. Problema hardware. Lo que te han dicho, ruido en la alimentación, es
> la
> causa más común. La solución, separar alimentaciones de potencia y lógica,
> sobredimensionar condensadores de filtro, añadir un condensadore de filtro
> de 100nF a la alimentación del PIC, lo más cerca posible de él, asegurar
> que
> las pistas de alimentación y masa están correctamente dimensionadas y
> trazadas, y que no sean compartidas por el circuito de potencia y el
> lógico.
>
ahora estoy rediseñando la placa para separar circuitos.
> Luego ya podría haber problemas más sutiles, como un acoplamiento
> incorrecto
> entre el PIC y otros chips (una resistencia en cada puerto utilizado que
> limite la corriente máxima a 15mA puede hacer milagros).
>
> Otro problema típico con control de motores mediante puentes H es no dejar
> tiempo suficiente para la conmutación en cada rama de la H, con lo que
> puedes tener corrientes instantáneas muy altas, cercanas a cortocircuito,
> que echen abajo la alimentación (esto además seguiría pasando aunque
> quitaras los motores).
>
lo que comenta Miguel. Lo miraré
> En fin, ya nos dirás.
>
muchas gracias a los dos
jugator EChMotor#140
En la placa antigua, ha llegado a fallar un par de veces en bastante tiempo.
En la placa nueva ha seguido fallando, si están los motores conectados.
Desconectando uno o los dos motores, ha dejado de reiniciarse.
La placa nueva de la antigua se diferencia en que la nueva integra toda la
circuitería en una única placa, mientras que la antigua es una placa para la
alimentación, PIC y motores y después conectores para la electrónica de
sensores, comunicaciones y demás.
A ver si hago la prueba separando circuitos a ver qué pasa
"jugator EChMotor#140" <jug...@gmail.com> escribió en el mensaje
news:fuhqir$hvv$1...@localhost.localdomain...
> en concreto un PIC18F452.
>[...]
Observer
alimentación.
Las masas de los distintos circuitos, motores y baterias deberian ir a un
punto (gordo)único y la alimentación (positivo) de la bateria y del L298 y
los motores desacoplarlos con una pequeña bobinita toroidal y un par de
condensadores formando un filtro paso bajo en "pi". Esto es lo que se me
ocurre. Yo tengo un robot con un pic 16F876 y lo tengo montado así.
"jugator EChMotor#140" <jug...@gmail.com> wrote in message
news:fuial2$pga$1...@localhost.localdomain...
jugator EChMotor#140
ceramicos justo en los pines de alimentación del PIC. Los que hay en la
placa son de poliéster, y el diseño que hice como que no favorece demasiado
que el camino sea el mas corto posible entre condensadores y pins de los
integrados.
Así que ahora a modificar el diseño y ale, a funcionar.
gracias!
"jugator EChMotor#140" <jug...@gmail.com> escribió en el mensaje
news:fuhqir$hvv$1...@localhost.localdomain...
jugator EChMotor#140
news:Nq5Pj.44282$zi5....@news.ono.com...
> Pienso que puede ser por el consumo de los motores, que mete un pico en la
> alimentación.
> Las masas de los distintos circuitos, motores y baterias deberian ir a un
> punto (gordo)único y la alimentación (positivo) de la bateria y del L298 y
> los motores desacoplarlos con una pequeña bobinita toroidal y un par de
> condensadores formando un filtro paso bajo en "pi". Esto es lo que se me
> ocurre. Yo tengo un robot con un pic 16F876 y lo tengo montado así.
>
se me había pasado este mensaje. En principio parece estar solucionado, pero
tomo nota por si finalmente los problemas persisten.
gracias