Ja, det är en haiku. (EDIT: fixat det ... det är nu faktiskt en Haiku)
Nej, jag ler inte.
Jag gör vissa standardtester; se vad som händer när en av de två strömskenorna kortsluts till GND på ett kretskort som jag designade. Vi pratar om en 12 V-strömskena som levereras av en strömförsörjning på bänkskivan, med en separat inbyggd 5 V-omvandlare som levererar den andra skenan på kretskortet (som min ATmega328PB är ansluten till).
12 V-skenan har en massa likströmsuttag som kommer att exponeras för slutanvändare. Så naturligtvis bestämde jag mig för att stoppa in en juvelerares skruvmejsel i en av dem för att genomföra mitt kortslutningstest.
Se, en puff rök från min ATmega328PB.
Jag tror att det betyder att något av följande hände:
Schematisk tid
Här är schemat för anslutningarna till ATmega328PB:
Här är alla scheman över saker i designen som har en anslutning till 12 V-skenan (VBAT + -skenan) och som styr GND-strömreturvägarna:
Och här är en schematisk bild av piputtagen och tillhörande uttagsdetekteringsstift (observera att dessa ansluter direkt till några av stiften på ATmega328PB utan seriemotstånd):
Kortslutningsplanen
Planen för att hantera kortslutningar på 12 V-skenan var att helt enkelt stänga av LOAD_FET N-kanal FET på grund av att en av två logiska villkor uppfylls i firmware:
- ADC-sampling med en hastighet av 1 Hz skulle detektera överströmstillståndet och orsaka att FET_LOAD-omkopplaren slutar leda och därmed bryter kortslutningsströmmen
- Spänningen som försörjer ATmega skulle gå i utbränt tillstånd och MCU skulle återställa och initiera FET_LOAD-omkopplaren till "av" och därmed stänga av kortslutningsströmmen
Den stora röken
Här är en oscilloskopprob av vad som händer med Vbat + skenan på CH1 (gul) och +5 skenan på CH2 (blå) när Vbat + kortsluts till GND via applicering av en juvelerars skruvmejsel på de exponerade ledningarna på en kabel som är ansluten till pipa-kretsen (jag stickade inte skruvmejseln i behållaren ) medan den drivs av en bänkskiva som är inställt på 12V @ 5 ampere:
Efter det hände skulle ATmega helt enkelt bli väldigt varmt när jag slog på kortet och fungerade effektivt som en kortslutning mellan dess + 5V ingång och signaljord. Jag lödde upp ATmega med varm luft och testade FET_LOAD N-kanal FET för att se om den var stekt. Det hade faktiskt misslyckats så att det inte längre skulle slå av eller på när en grindspänning applicerades på +5 eller signaljord, utan istället fungerade någonstans i skymningszonen däremellan. Det sjönk cirka 2,3 volt medan det ledde ~ 200 mA, oavsett om det var "på" eller "av" när en belastning anslogs till piputtaget.
Hunch
Hade en aning att eftersom FET var skadad att vektorn för skada på ATmega kan ha orsakats av överföring av en hög spänning genom FET-avloppet till dess grind och vidare till MCU. Gjorde några efterföljande tester med lägre spänningar som levererade 12V-skenan. Observera att de tre första bilderna i princip är desamma, men med olika toppströmmar. När ATmega stängts av (på grund av kollapsad spänning på Vbat + -skenan) blir LOAD_GND_ENABLE -signalen från MCU (blå, nedan) i sin tur låg och skär FET_LOAD växla.
Legend:
CH1 = Spänning över Rshunt (0,005 ohm) CH2 = Spänning vid LOAD_GND_ENABLE-signal (ansluten till ATmega)
Vbat + levereras vid 6V:
Vbat + levereras vid 7V:
Vbat + levereras vid 8V:
Vbat + levereras vid 9V:
På den sista slutade strömmen aldrig öka och signalen LOAD_GND_ENABLE gjorde en funky dans, men allt som allt verkar det som att gränserna aldrig överträffades på LOAD_GND_ENABLE pin (åtminstone tror jag inte att de var ... Jag har bara ett 2-kanals omfång och skulle ha varit tvungen att mäta + 5V skenan för att veta vad spänningen på LOAD_GND_ENABLE wrt Vcc).
Nästa steg
Jag har bara 1 styrelse kvar som kan offras, därför är min plan att:
-
Använd ett tomt ATmega328PB så att alla dess 'stift kommer att vara standard till hög impedens utan kringutrustning konfigurerad / initierad. Upprepa kortslutningstest för att se om ATmega328PB fortfarande går upp i rök. Om det inte går förlorat måste MCU misslyckas eftersom det hämtade / sjönk för mycket ström ur en av dess stift som konfigurerades som en utgång medan den körde firmware i tidigare tester.
-
Testa med en ATmega328PB monterad på ett brytkort (tyvärr kommer detta chip inte i DIP-paket) anslutet till PCB via svängtrådar. Börja selektivt att ansluta en enda svängtråd i taget, köra testet och se vilken svängtråd som slutligen blir den som är ansvarig för att steka ATmega328PB.
-
Beställ ett nytt PCB-exempel med ändrad layout så att alla spår som ansluter till ATmega328PB är anslutna med lödbryggor som kan lödas för hand när jag testar. På detta sätt kan kortslutningstestet (och alla andra tester) utföras med ATmega ansluten till ett begränsat antal signaler åt gången och gör det enkelt att ansluta alla andra externa kretsar till dessa lödbroar för att styra dem oberoende av ATmega .
Ja, det är verkligen en fråga!
Och frågan / frågorna är:
- ser någon något här som jag inte ser. Är det uppenbart? Jag hoppas att det inte är uppenbart ...
- Vad skulle ditt nästa steg vara?