Reinitialisation intempestive d'un ATMEL

[HAYAC]

Cette remarque est juste,
Il n'est aucunement mentionné sur aucun de package que 2 peut être la masse du composant entre autre
-----

[inviteba26711f]

Merci pour vos réponses.
@Aurélien : pourquoi cette condescendance à chaque post?

[HAYAC]

Je pense vraiment que ton problème ce situ à ce niveau,
As-tu la possibilité de modifier ton circuit pour les pin 1 et 2-3 ?
Ne serais que pour test et validation de cette infos ?

[inviteeb160de1]

@Aurélien : pourquoi cette condescendance à chaque post?

Parce que dès ma première intervention je sollicite un schéma, et le torchon que tu a posté n'en ai pas un puisque erroné dans le pin assignment et qu'il est incomplet. Je me repete, tu fais l'autruche, ça me gonfle. CQFD.
T'as probablemet soit un pb de schéma aussi con que des pins pas connectées comme il faut, soit un problème de surcharge sur ton bus USB. On ne voit même pas le circuit de reset de ton micro, on ne sait pas si son BOR est activé et à quel seuil, si tu as un BOR externe....bref, tu te vexes mais on avance pas...

[inviteba26711f]

Je pense pas être hyper désagréable par message. Je vois de ton côté des messages constructifs, mais toujours la pique. J'veux dire, si je suis chiant, autant ne pas répondre, je comprendrai.
Tu vois, c'est tout con, mais le "On parie qu'il n'a pas testé d'autres alimentations" est super condescendant. Parce que au final, si c'est le cas? J'suis juste un gros boulet? Super, je suis heureux de venir ici.


Au niveau du package, c'est vraiment un package 5 pins, donc je sais pas si le numéro à quelque chose à voir avec celui des 8. Je vais checker.
De base je cherchai également un problème pas vraiment de ce côté là. D'ou mon insistance sur les schémas. Et effectivement, j'ai tort. Mais au final, j'ai pas l'air d'être le seul vexé.

Au niveau de l'alimentation, j'ai essayé différents ports USB, et je connaissais pas l'alimentation maximale USB, j'avoue que ça m'a pas sauté aux yeux.
Effectivement, je prends une alimentation régulée, et ça a l'air de pouvoir fournir tout ça.
Je ne comprends par contre absolument pas à quel endroit j'ai un appel de courant qui nécessite une alimentation plus puissante. J'ai une fuite quelque part et je ne vois pas ou.

Cela reste à confirmer que mon alimentation stabilisée marche, et cela ne résouds pas ma recherche de fuite de courant, ou de cause de ce problème.


Je comprends mieux la manière dont vous abordez le sujet. J'essayerai de faire au mieux la prochaine fois.

http://www.mouser.com/ds/2/405/tps2051b-448966.pdf : Voila la datasheet du composant. Mon "Torchon" a les pins assigments du DBV PACKAGE, et semble correct, à ceci près dans l'entête du composant.

[inviteeb160de1]

Ah ben on avance.

Au niveau de l'alimentation, j'ai essayé différents ports USB, et je connaissais pas l'alimentation maximale USB, j'avoue que ça m'a pas sauté aux yeux.

Pourtant tu utilises des switchs TPSxxx qui sont justement destinés à protéger les alimentations de host USB (la norme l'oblige)

http://www.mouser.com/ds/2/405/tps2051b-448966.pdf : Voila la datasheet du composant. Mon "Torchon" a les pins assigments du DBV PACKAGE, et semble correct, à ceci près dans l'entête du composant.

Effectivement, ton schema et ton post parle d'un TPS2051D alors que tu as mis un "B". C'est le genre d'erreur qui peut être catastrophique en production (exemple entre les différentes déclinaisons d'une bête BAT54).

Effectivement, je prends une alimentation régulée, et ça a l'air de pouvoir fournir tout ça.
Je ne comprends par contre absolument pas à quel endroit j'ai un appel de courant qui nécessite une alimentation plus puissante. J'ai une fuite quelque part et je ne vois pas ou.
Cela reste à confirmer que mon alimentation stabilisée marche, et cela ne résouds pas ma recherche de fuite de courant, ou de cause de ce problème.

Tu valides qu'avec une autre source de tension ça fonctionne ?
Ce qui est curieux c'est que ton problème arrive lorsque tu relaches la charge, et pas quand tu l'amorces. C'est quoi exactement cette charge, quelle impedance ? Tu as dit qu'elle est simple, mais je veux bien pouvoir en juger aussi.
T'es bien certain que sur ton routage ta pin 4 du boitier SOT23-5 du TPS2051B est bien placée ?
Ya quoi d'autre connecté à ton AVR? Isole ton probleme et réduit ton soft à ce qu'il y a de plus basique : commutation on/off de ta charge.

Je comprends mieux la manière dont vous abordez le sujet. J'essayerai de faire au mieux la prochaine fois.

Regle numéro UNO dans tout probleme electronique quel qu'il soit : vérifier la source d'alim....C'est comme un humain, s'il mange de la m...., il aura des soucis.
Et un port USB c'est presque la pire source qui soit : parasites, limitations de courant...
Regle numéro 2 : isoler, simplifier pour mieux cerner.
En tout cas c'est comme ça que je fonctionne.

[inviteba26711f]

Pourtant tu utilises des switchs TPSxxx qui sont justement destinés à protéger les alimentations de host USB (la norme l'oblige)

D'un point de vue courant, je pensais pas faire crasher mon circuit. L'alimentation globale est maximum de 70mAH pour mon circuit, et pour les derniers tests j'eteignais tout, je faisais fonctionner uniquement ce que j'ai mis en schéma. Alors dépasser le 550mA...

Effectivement, ton schema et ton post parle d'un TPS2051D alors que tu as mis un "B". C'est le genre d'erreur qui peut être catastrophique en production (exemple entre les différentes déclinaisons d'une bête BAT54).

Totalement.
Ce qui me permet de me reprendre, c'est que le TPS2051D n'existe pas en 5 pins.

Tu valides qu'avec une autre source de tension ça fonctionne ?

Oui! Et c'est assez frustrant.
Comme tu le dis juste après, c'est quelque chose à checker de base. Surtout vu les port USB de mon PC. Mais là.... C'est pas comme si je demandais quelque chose d'énorme, en théorie, c'est 25mA max pour l'ordre HIGH.

Ce qui est curieux c'est que ton problème arrive lorsque tu relaches la charge, et pas quand tu l'amorces. C'est quoi exactement cette charge, quelle impedance ? Tu as dit qu'elle est simple, mais je veux bien pouvoir en juger aussi.

La charge qui est alimentée par le 3V3 sensor va être : deux resistances en parrallèle d'une centaine de ohms pour la partie chauffe.
Et deux resistances de charge d'une centaine de kilo ohms, en parralèlle également.

T'es bien certain que sur ton routage ta pin 4 du boitier SOT23-5 du TPS2051B est bien placée ?
Ya quoi d'autre connecté à ton AVR? Isole ton probleme et réduit ton soft à ce qu'il y a de plus basique : commutation on/off de ta charge.

Oui chef! Le routage me semble correct, et j'ai tout éteins, pour ne faire fonctionner que ma charge et sa commutation. J'ai rien d'autre sinon!

Regle numéro UNO dans tout probleme electronique quel qu'il soit : vérifier la source d'alim....C'est comme un humain, s'il mange de la m...., il aura des soucis.
Et un port USB c'est presque la pire source qui soit : parasites, limitations de courant...
Regle numéro 2 : isoler, simplifier pour mieux cerner.
En tout cas c'est comme ça que je fonctionne.

J'apprends !

[invitee05a3fcc]

L'alimentation globale est maximum de 70mAH pour mon circuit, et pour les derniers tests j'eteignais tout, je faisais fonctionner uniquement ce que j'ai mis en schéma. Alors dépasser le 550mA...

Tu vas encore faire hurler sous les chaumières !
- mAh, c'est une énergie
- mA, c'est un courant

La charge qui est alimentée par le 3V3 sensor va être : deux resistances en parrallèle d'une centaine de ohms pour la partie chauffe.

Pourquoi utiliser un composant ésotérique ?
Ta charge peut être coupée par le 0V ? Un NMOS (bien choisi) et c'est torché .

[inviteba26711f]

Un NMOS Bien choisi...?
Disons que couper avec du 0V, c'était un peu le principe du TPS... Ou alors j'ai mal compris..?

[invitee05a3fcc]

Disons que couper avec du 0V, c'était un peu le principe du TPS... Ou alors j'ai mal compris..?

Le TPS est high side (coupure du 3,3V vers la charge au 0V)
Le NMOS est low side (coupure du 0V vers la charge alimentée en 3,3V)

[inviteeb160de1]

Pourquoi utiliser un composant ésotérique ?
Ta charge peut être coupée par le 0V ? Un NMOS (bien choisi) et c'est torché .

Le TPS a l'avantage d'avoir une protection court circuit (pratique si capteur externe sur fils...), ce que n'a pas un MOS. Cela dit, dans le projet de poupoule, la limitation de courant est réglé trop haut pour être efficace (il faudrait prendre une ref 100mA), le regulateur 3V3 et l'USB flanchera avant...

[inviteeb160de1]

j'ai tout éteins, pour ne faire fonctionner que ma charge et sa commutation. J'ai rien d'autre sinon!

Que se passe-t-il si tu fais tes cycles de commutation et que tu enleves ta charge ?

Pendant combien de temps tu laisses ta charge active avant de la couper ?

Pour avancer davantage, je crains qu'il ne faille un vrai schéma complet pour vérifier ce qu'il y a autour.

[inviteeb160de1]

Je viens de voir un truc dans la datasheet. Sur ta référence TPS2051B, en fait l'entrée EN est à logique positive et non négative (comme il semble l'être à première vue sur la premiere page de la datasheet). Autrement dit, ton probleme survient lorsque tu mets sous tension ta charge. Et non pas lorsque tu cesses de l'alimenter.
Ce qui pose deux questions :
- pourquoi se fait il que tu dit que ton capteur fonctionne lorsque ton signal EN est à l'état bas (et donc qu'il est en pratique non alimenté) => serait il alimenté par une autre source ?
- qu'y'a-t-il vraiment sur ce capteur qui provoque une chute de courant lorsque tu le branches ?

Que mesures tu en consommation sur ton alimentation lorsque tu alimentes ton capteur (donc avec EN = haut) ?

Je vais insister...un schéma complet de ton capteur ? A-t-il des liaisons vers ton micro, lequel pourrait faire des injections de tensions via des I/O ? Ce qui pourrait avoir pour conséquence de créer une condition de latchup lorsque tu viens lui appliquer une tension d'alim sur son VCC...et donc surconso et donc plantage.

[inviteba26711f]

Pardon Aurélien, encore ma faute. C'est la version 2041 que j'ai, pas la 51 (ce qui correspond avec le package Eagle que j'ai, et le /EN.

Pour autre info, j'ai bien du courant lorsque le EN est bas, et je chute à 0 en sortie de capteur lorsque j'ai EN=1. Pas de pics de surconso.

A-t-il des liaisons vers ton micro, lequel pourrait faire des injections de tensions via des I/O ? Ce qui pourrait avoir pour conséquence de créer une condition de latchup lorsque tu viens lui appliquer une tension d'alim sur son VCC...et donc surconso et donc plantage.

Ok je vais essayer de comprendre ta phrase après t'avoir répondu XD.
J'ai évidemment une liaison AnalogRead entre la sortie de mon capteur qui récupère une tension d'un "pont diviseur". Ces Analog sont définies en tant que INPUT.

Je me doute ensuite que le schéma soit nécessaire. Mais je peux vraiment pas ^^.
Pour retirer la charge active, c'est assez compliqué de la virer. C'est ma prochaine étape, au vu de ce que je comprends.

Merci beaucoup pour ces messages. Je ne le dis pas à chaque fois, mais Merci ^^

[inviteeb160de1]

Pardon Aurélien, encore ma faute. C'est la version 2041 que j'ai, pas la 51 (ce qui correspond avec le package Eagle que j'ai, et le /EN.

Comment veux tu que je reste calme !

[invitee05a3fcc]

Comment veux tu que je reste calme !

Moi, je t'admire ....... il y a longtemps que je serais monté dans les tours (moteur !)

[inviteeb160de1]

J'ai évidemment une liaison AnalogRead entre la sortie de mon capteur qui récupère une tension d'un "pont diviseur". Ces Analog sont définies en tant que INPUT.
Je me doute ensuite que le schéma soit nécessaire. Mais je peux vraiment pas ^^.

C'est un capteur de pognon planqué ou quoi pour que tu ne veuilles pas en donner le schéma ?
Allez, je mise sur le fait que tu me caches encore un truc, que tu as une IO de ton AVR qui envoie du 3V3 sur une IO de ton capteur lorsqu'il n'est pas alimenté, ce qui cause l'effondrement de l'alim du micro, lequel se resette à cause de son BOR, et du coup ton capteur redevient alimenté correctement et ne pompe pas de jus en trop.

[jiherve]

bonsoir,
en effet si l'I/O de l'ADC n'est pas configurée en entrée (sans pull up cela serait mieux) cela pourrait être amusant.
JR

[jiherve]

re
il serait intéressant de voir ce qui se passe si le "capteur" n'est pas branché.
JR

[stefjm]

Tu vas encore faire hurler sous les chaumières !
- mAh, c'est une énergie

Souvent utilisé comme énergie si on connait la tension, mais sinon, c'est quand même une charge électrique.
Pour que ce soit une énergie, il faut multiplier par une tension : mA.h.V=W.h

[inviteba26711f]

Etant un gros sagouin, j'ai pas réussi a déssouder mes capteurs (Impossible avec mes outils), donc j'ai dégommé la patte OUT du TPS et.... Mon alimentation globale part en vrille, et plus rien ne marche. J'ai du cramer des composants autour

[inviteeb160de1]

Vu que t'as un scope, t'aurais du regarder tes niveaux de tension sur toutes les IO de ton capteur avant de tenter des modifs hard..
Ton capteur il a uniquement une liaison analogique vers ton micro ?

[inviteba26711f]

Tout à fait. Une liaison analogique qui n'était pas définie en input dans le code arduino. J'ai fais les modifications nécessaire sans que rien ne change.
Le scope montrait pour le moment qu'au moment de la coupure, la sortie analogique décroissait pour arriver à 0V. Pas de pics, de phénomènes étrange lors de la mise en OFF.
PS : j'en ai un deuxième... Ca m'emmerdes juste ^^

[inviteeb160de1]

Quand t'en auras marre de galérer, tu posteras un schéma et ton code...

[inviteeb160de1]

le code arduino

Post 53, on apprend l'existence d'un arduino dans le projet. On est proche de la médaille là.

[inviteba26711f]

Très bien, je reviendrai à ce moment là alors.

"Bonjour Futura!
Je viens à vous parce que j'ai un problème, et parce que les admins ne me laisseraient pas poster un message juste pour faire coucou.

Alors, mon problème :
J'ai un ATMEGA32U4,"

Post 1, présence d'un ATMEGA32U4, qui est chargé par le logiciel Arduino avec un code arduino, en effet.

[inviteba26711f]

Cela doit sembler évident de préciser que c'est du arduino. Pas pour moi. Encore une fois désolé d'être inexpérimenté;
De toute facon, au bout de la 20ème demande de schéma et de code, j'ai bien compris le message. Mais a partir du moment ou je ne posterai pas plus... Autant arreter les occurrences, et juste vous remercier du temps accordé.
Bonne continuation
Antoine

[HAYAC]

Plusieurs constats et remarques :
- Comme à l'habitude, le ton monte vite et les paroles s’envolent ... (Arrêtez les sur doses de caféine ou autre).
- Tous le monde n'a pas la même logique, analyse, connaissances, niveau et autres (Ce qui ce respect tout de même).
- Les demandes mal formulés (Manque d'infos ou compte goute, Ton inapproprié ...) sont, et il faut nous comprendre, pénible car longue à décortiquer (Faite un petit effort).
- Enfin ce qui sont vraiment agacé, abstenez-vous simplement de répondre, ce qui rendra la lecture des post moins pénible ...

Cordialement,

[inviteeb160de1]

- Tous le monde n'a pas la même logique, analyse, connaissances, niveau et autres (Ce qui ce respect tout de même).
- Les demandes mal formulés (Manque d'infos ou compte goute, Ton inapproprié ...) sont, et il faut nous comprendre, pénible car longue à décortiquer (Faite un petit effort).

Ce n'est pas un problème de respect de niveau plus faible, c'est un problème d'avoir un mec qui fait un montage brouillon et dont il ne veut pas donner le schema ou le code à priori pour des questions de confidentialité (même la réponse à la question "pourquoi tu ne donnes pas de schéma" est confidentielle, c'est dire !)...C'est non seulement pénible, mais quand on nous prend pour des cons, faut pas s'étonner...Surtout quand je veux aider un mec qui est potentiellement un concurrent de mon activité (et c'est pas le seul...).

[HAYAC]

Bonjour Aurélien et tout le monde ,

A mon plus grand regret, nous somment dans une aire ou la communication "Réel, a l’ancienne" n'est plus d'actualité ...
Formuler une demande complète avec l'ensemble des problématiques (Technique, Confidentialité, Maitrise du sujet, Présentation de l'interlocuteur ...) est difficile pour beaucoup de monde.
Je ne pense pas qu'il nous prenne pour des cons mais simplement qu'il a une épée Damoclès au dessus de la tête concernant ce projet tant sur le point de la confidentialité que sur le fait d’être bloqué.
Je pense qu'il serait bon de reprendre l'ensemble du problème, avec ses considérations, si nous voulons pouvoir clôturer ce post avec une solution.
Je propose donc au demandeur de nous refaire un check complet :
- Schéma "à jour" complet de la partie concerné.
- Résultat de toute les mesures effectuer.
- État actuel du défaut.
- ...
(Pour ce qui est de divulguer, par exemple une terminaison, il n'y à pas de problème si celle-ci est représenté par ses caractéristiques plutôt due son model qui nous indiquerait son usage).

De cette façon, nous pourront rapidement résoudre ce petit problème qui j'en suis sur est hyper simple et évidant ...

Cordialement,