Oui, c'est un haïku. (EDIT: corrigé ... c'est maintenant en fait un Haiku)
Non, je ne souris pas.
Je fais des tests standard; voir ce qui se passe lorsque l'un des deux rails d'alimentation est court-circuité à GND sur un PCB que j'ai conçu. Nous parlons d'un rail d'alimentation 12 V alimenté par une alimentation de paillasse, avec un convertisseur abaisseur 5 V intégré qui alimente l'autre rail du PCB (auquel mon ATmega328PB est connecté).
Le rail 12 V a un tas de prises DC baril qui seront exposées aux utilisateurs finaux. Alors, naturellement, j'ai décidé de coincer un tournevis de bijoutier dans l'un d'eux pour effectuer mon test de court-circuit.
Voici une bouffée de fumée de mon ATmega328PB.
Je pense que cela signifie que l'une des choses suivantes s'est produite:
Temps schématique
Voici le schéma des connexions à l'ATmega328PB:
Voici tous les schémas des éléments de la conception qui ont une connexion au rail 12 V (le rail VBAT +) et qui contrôlent les chemins de retour du courant GND:
Et voici un schéma des prises de barillet et des broches de détection de prise associées (notez que celles-ci se connectent directement à certaines des broches de l'ATmega328PB sans résistance série):
Le plan de court-circuit
Le plan pour traiter les courts-circuits sur le rail 12 V consistait simplement à désactiver le FET à canal N LOAD_FET car l'une des deux conditions logiques était remplie dans le micrologiciel:
- L'échantillonnage ADC à une fréquence de 1 Hz détecterait la condition de surintensité et provoquerait l'interruption du conducteur FET_LOAD, coupant ainsi le courant de court-circuit
- La tension d'alimentation de l'ATmega se mettrait en panne et le MCU réinitialiserait et initialiserait le commutateur FET_LOAD sur "off", coupant ainsi le courant de court-circuit
The Big Smoke
Voici une sonde d'oscilloscope de ce qui arrive au rail Vbat + sur CH1 (jaune) et au rail +5 sur CH2 (bleu) lors du court-circuitage de Vbat + à GND via l'application d'un tournevis de bijoutier aux fils exposés d'un câble qui est branché sur le circuit jack barrel (je n'ai pas enfoncé le tournevis dans la prise ) alors qu'il est alimenté par une alimentation de paillasse qui est réglée sur 12V @ 5 ampères:
Après cela, l'ATmega devenait tout simplement très chaud chaque fois que je mettais la carte sous tension, et agissait effectivement comme un court-circuit entre son entrée + 5V et la masse du signal. J'ai dessoudé l'ATmega avec de l'air chaud et testé le FET FET_LOAD N-channel pour voir s'il était frit. En effet, il avait échoué au point de ne plus s'éteindre ni s'allumer complètement lorsqu'une tension de grille était appliquée à +5 ou à la masse du signal, mais fonctionnait plutôt quelque part dans la zone crépusculaire entre les deux. Il baissait d'environ 2,3 volts tout en conduisant ~ 200 mA, qu'il soit "allumé" ou "éteint" lorsqu'une charge était branchée sur le cric du canon.
Pressentiment
Si le FET a été endommagé, le vecteur des dommages à l'ATmega peut avoir été causé par la transmission d'une haute tension via le drain du FET à sa grille et au MCU. A fait des tests ultérieurs avec des tensions plus faibles alimentant le rail 12V. Notez que les trois premières images sont fondamentalement les mêmes, mais avec des courants de crête différents. Une fois l'ATmega arrêté (en raison de la chute de tension sur le rail Vbat +), le signal LOAD_GND_ENABLE fourni par le MCU (bleu, ci-dessous) devient à son tour bas, coupant le commutateur FET_LOAD .
Légende:
CH1 = tension aux bornes de Rshunt (0,005 ohm) CH2 = tension au signal LOAD_GND_ENABLE (connecté à ATmega)
Vbat + fourni à 6V:
Vbat + fourni à 7V:
Vbat + alimenté en 8V:
Vbat + fourni à 9V:
Sur ce dernier, le courant n'a cessé d'augmenter et le signal LOAD_GND_ENABLE a fait une danse funky, mais dans l'ensemble, il semblerait que les limites maximales n'aient jamais été dépassées sur la broche LOAD_GND_ENABLE (au moins, je ne pense pas qu'elles l'étaient ... Je n'ai qu'un oscilloscope à 2 canaux et j'aurais dû mesurer le rail + 5V pour connaître la tension sur LOAD_GND_ENABLE par rapport à Vcc).
Prochaines étapes
Il ne me reste qu'une planche à sacrifier, mon plan est donc de:
Utilisez un ATmega328PB vierge afin que toutes ses broches soient par défaut à haute impédance sans aucun périphérique configuré / initialisé. Répétez le test de court-circuit pour voir si l'ATmega328PB continue de monter en fumée. Si cela ne va pas, le MCU doit avoir échoué car il cherchait / coulait trop de courant sur l'une de ses broches configurées en sortie alors qu'il exécutait le firmware dans les tests précédents.
Testez avec un ATmega328PB monté sur une carte de dérivation (malheureusement, cette puce ne vient pas dans des boîtiers DIP) connectée au PCB via des fils volants. Commencez sélectivement à connecter un seul flywire à la fois, exécutez le test et voyez quel flywire finit par être celui qui est responsable de la friture de l'ATmega328PB.
Commandez un nouvel échantillon de PCB avec une disposition modifiée de sorte que toutes les traces se connectant à l'ATmega328PB soient connectées par des ponts de soudure qui peuvent être soudés à la main pendant mon test. De cette façon, le test de court-circuit (et tout autre test) peut être effectué avec l'ATmega connecté à un nombre limité de signaux à la fois, et facilite la connexion de tous les autres circuits externes à ces ponts de soudure pour les contrôler indépendamment de l'ATmega. .
Oui, c'est vraiment une question!
Et la (les) question (s) est:
- quelqu'un voit-il quelque chose ici que je ne vois pas. Est-ce évident? J'espère que ce n'est pas évident ...
- Quelle serait votre prochaine étape?