p-mosFET schakelt spanning voor BMP280 , Arduino crasht

Voor een low power opzet laat ik de spanning voor twee BMP280 sensoren schakelen door een p-mosFET (A19T en si2301) via poort D3.

Maar de Arduino crasht zodra de mosFET wordt uitgeschakeld. Ik kan dat overigens simuleren door zelf hard de spanning van de BMP280 af te halen.

Maar .... het probleem doet zich NIET voor als een BC557 pnp transistor wordt gebruikt om de spanning te schakelen. Dat gaat prima.

Wat is hier de logica?

Ik gebruik de cactus_io_BME280_I2C.h library omdat deze twee BME's ondersteunt.

Shiptronic

Overleden

Wie de vraag stelt, zal met het antwoord moeten leren leven.
Arco

Special Member

schakelen door een p-mosFET (A19T en si2301)

Welke van de twee? Hoe groot is de gate weerstand?

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Is alles 3.3V ? Kunnen ze dan niet direct aan de poort ? De stroom is maximaal in de tientallen uA's.
Let ook goed op onbekende libraries. Het is niet gezegd dat hij goed omgaat met wegvallen van de sensor.

Inderdaad op 3V3.
Verdere waarneming: de voedingsspanning voor de BME's via de pnp transistor is 3.25V en via de FET 3.29V, gelijk aan de gemeten Vcc.

Opmerkelijk is dat als de BME's gevoed worden door de pnp transistor, de Arduino NIET crasht als ik de spanning hard van de BME's afhaal.

Dit in tegenstelling tot direct gevoed of via de p-mosFET.

Ik heb allebei de p-mosFETs getest. Ik gebruik geen gate/basis weerstand.

De BME's kunnen wel aan de poort, maar ik wil ook nog een RFM95 schakelen en die neemt wel wat meer tijdens de zend fase.

Is zeker dat ze in dat geval niet aan blijven op het lek van de transistor ?
Of via de diodes en de pullups op de I2C danwel de signalen op de SPI-bus ?

[edit]
Als ik hier test met een BME280 komt hij niet werkend op als ik de voeding weer aansluit, maar de 'Duino crashed intussen niet. Ik gebruik de Adafruit library.

[edit 2]
In slaap gebruiken ze 100 nA. Het lijkt niet zo de moeite ?

[Bericht gewijzigd door Aart op zaterdag 27 juni 2020 20:49:39 (10%)

Nee de BMP komt niet werkend meer op, maar ik doe dan steeds opnieuw een initialisatie. Dat gaat in principe prima (met een transistor).

De ProMini crasht dus als de spanning van de BMP's wordt afgehaald: manueel of via een p-mosFET, en NIET als ze (een iets lagere) spanning kregen via een pnp transistor (en dan ook niet manueel).

[edit]

De cactus_io_BME280_I2C.h library voorziet niet in een slaapstand voor de BMP/E's

Zonder herinitialisatie worden wel waarden gemeten, maar die wijken af, vooral de drukmeting

[Bericht gewijzigd door GdV op zaterdag 27 juni 2020 21:05:02 (11%)

--

[Bericht gewijzigd door GdV op zaterdag 27 juni 2020 21:05:19 (100%)

Arco

Special Member

Ik zou een weerstand van ~100 Ohm tussen de gate zetten...
Als die BME aan de I2C/SPI bus hangt kunnen daar ook lelijke dingen gebeuren als je zomaar de voeding er vanaf haalt...
(het is niet voorspelbaar wat er dan gebeurt, omdat die sensor nooit gemaakt is voor plots wegvallende voedingsspanning)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Ja dat begrijp ik, maar het blijft vreemd dat schakelen met een pnp transistor goed gaat, maar met een p-mosFET dus niet.

Het enige verschil dat ik zie is de iets verlaagde voedingsspanning door de transistor.

Het is al een beetje genoemd, maar het eerste waar ik aan dacht is: wat doe je met de pull-ups van de i2c bus? Die zul je ok weg moeten halen in sleep. En wat doet de bus vd Arduino dan? Het is een master poort, ok, maar ja.

Verder: wat is "hij crashed"? Een micro doet altijd iets, dus ook als ie gecrashed is. In welk stuk vd software hangt ie dan uit? Kan het zijn dat je een interrupt genereert of zo? Misschien heb je nog andere interfaces waar je op inspreekt door het uitschakelen?

ps, over de opmerking hierboven (pnp vs fet), is de spanning wel echt weg bij die pnp? Misschien toch weven de schakelingetjes posten.

[Bericht gewijzigd door flipflop op zaterdag 27 juni 2020 21:27:59 (12%)

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein

Tja, ik doe idd niets met de i2c bus lijnen.

De crash: de serial output stokt, en (pingpong) ik hoor dat de COM-poort eruit vliegt. De ProMini probeert daarna zonder resultaat weer op te starten.

Het ligt niet persé aan de software omdat ik het handmatig ook kan simuleren. Nee geen andere zaken aangesloten dan de twee BMP's

De spanning is misschien niet echt weg bij de pnp, maar ik kan dat dan handmatig doen zonder dat de ProMini crasht.

Image: vervang BS250 door genoemde p-mosFETs (de BS250 die ik uit China ontving bleken geen p-mosFETs te zijn maar pnp transistor)

[Bericht gewijzigd door GdV op zaterdag 27 juni 2020 21:44:50 (13%)

Arco

Special Member

Probeer de 100 Ohm weerstand, dat voorkomt/beperkt in ieder geval ringing (dat kan ook allerlei ongewenste gevolgen hebben)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
EricP

mét CE

De crash:

Dat is geloof ik een mode kreet voor 'doet het niet meer' he?

de serial output stokt, en (pingpong) ik hoor dat de COM-poort eruit vliegt.

Oh. En waar vliegt-ie dan heen?

Wat je feitelijk beschrijft is dat winshit om de een of andere reden struikelt over iets wat er op USB gebeurt...

De ProMini probeert daarna zonder resultaat weer op te starten.

Wat bedoel je daarmee? (ofwel: wat neem je waar?)

zonder dat de ProMini crasht.

Zoals flipflop al beschreef: zo'n ding kan niet 'crashen'. Het doet altijd iets. Dus de vraag is... waar in software hangt dat ding uit?

Mijn gokje is dat eea. USB powered is en dat daar iets gebeurt. Waarom met een FET wel en met een bipolaire tor niet, heeft waarschijnlijk met de steilheid van de flanken te maken.

Ik kan me ook wel voorstellen dat de host USB controller over z'n nek gaat als er stroom getrokken wordt en dat houdt zeer abrupt op - zeker in combinatie met een wat langere kabel (inductie) en gebrek aan ontkoppeling / bypassing.
Win-ellende heeft geen dmesg he? Dan zou je eens kunnen kijken waarom het ding 'eruit vliegt' (kooi dicht doen helpt zeker niet?).

Begin eens met je voeding op orde brengen. En daarmee begin je door eerst eens te kijken hoe dat nu in elkaar zit. Gokje wagen dat dat wel ergens rammelt?
Daarna kun je eens kijken hoeveel stroom er nou eigenlijk loopt als er geschakeld wordt. En of dat ellende zou kunnen veroorzaken.
Voeden uit iets wat daarvoor bedoeld is kan ook al een hoop gez**k voorkomen.

Tenslotte over zomaar ergens de voeding af halen: meestal is dat een slecht idee. I2C werkt met pull-up weerstanden. Met een beetje mazzel heeft dat device protectie dioden aan de ingangen zitten. Dat betekent dan dat het voeding via I2C en de protection dioden gaat krijgen. Geen idee hoe 'lekker' die voeding is en hoe eea. reageert. Dat gezegd hebbende: ik geloof op het moment niet dat dit je probleem is. Het is wel een vreselijk brak design op deze manier...

Kortom: beginnen bij het begin. Hoe zit je voeding in elkaar? Zit er ergens iets van bypassing / decoupling? Zo ja: waar en hoeveel?

Op 27 juni 2020 21:41:09 schreef GdV:
De crash: de serial output stokt, en (pingpong) ...

Dat betekent dat de uart-usb interface chip geen voeding meer krijgt, anders had Windows nog gewoon die chip gezien op z'n poort. Dus, mijn voorzichtige conclusie is dat je de voeding kortsluit met die tor. Dat lukt blijkbaar beter met de fet dan met de bipolaire. Nogmaals, schets de gebruikte schakelingen eens.

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein

@ Arco: de 100 ohm weerstand brengt geen verandering in gedrag
@ Eric: ik gebruik idd usb power uit windows computer. Ik heb nu een batterij getest, en dan "crasht"ie niet.
@ flipflop: ik heb iets eerder plaatje gepost

Arco

Special Member

Is de stroom die je uit de USB trekt niet te hoog? (USB2 default max 100mA)
Er zit natuurlijk nog meer tussen, want de USB is 5v en jij gebruikt 3.3v...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Ik meet ongeveer 7mA (ik heb de powerLED en regulator verwijderd).

Je hebt kans dat er via de pull-ups van de i2c bus alsnog een stroom richting BME280 gaat lopen die hem van voedingsspanning voorziet.
Sommige i2c decvices reageren nogal gek op het afschakelen van de voedingsspanning.
Zoals andere ook al hebben gezegd is het niet nodig om een transistor of fet tussen de voeding te zetten. Een IO pin van een arduino kan dik 30mA leveren en dat is ruim voldoende voor een BME280.

Zelf zet ik de BME280 in slaap als hij niet benodigd is waardoor hij nog maar 200µA trekt, geen extra hw benodigd.

c code:


settings.mode = BME280::Mode_Sleep; //Put the BM280 sensor in sleep mode
bme.setSettings(settings);

De TS heeft al gezegd dat er in de toekomst meer verbruikers geschakeld gaan worden, die samen dusdanig veel stroom trekken dat het niet door een I/O pin kan. Daarnaast is het nuttig om het probleem te begrijpen, zelfs als de constructie niet strikt noodzakelijk was geweest.

Dat er stroom door de ESD diodes zou kunnen lopen is bekend, en dat is zeker niet netjes, maar dat zou het huidige probleem nog niet verklaren.

Wat mij verbaasd is dat het mis gaat bij het uitschakelen; bij het inschakelen moeten er waarschijnlijk wat condensators opgeladen worden, waarmee je mogelijk lokaal je voedingsspanning onderuit trekt, waardoor de microcontroller en FTDI chip resetten

Het feit dat de FDTI chip contact verliest, bewijst m.i. dat er iets op de voeding gebeurd. De enige verklaring die ik zo kan bedenken is dat er nauwelijks capaciteit aanwezig is, alleen een paar 100nF caps, en dat die samen met de kabel en slecht gedempte kring vormen die gaat slingeren. In dat geval zou een kleine elco van de 5V naar de ground bij de microcontroller het wellicht kunnen oplossen.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
EricP

mét CE

Ik meet ongeveer 7mA.

Ja, ok. Tot je door het uitschakelen en dat op een lompe manier doen iets in latch-up zet. Toevallig lukt dat met die FET. En waarschijnlijk lukt het net niet op die batterij.

Ter leering ende vermaeck: zet in software beide I2C lijnen eens laag voordat je de boel uitschakelt - ik gok er even op dat er verder niks aan hangt 'naar plus'. Dan zou je eea. echt uit zetten.
Gaat die USB dan nog steeds onderuit?
Let wel: het is een gewoon een experiment. Dus geen 'oplossing'.

bprosman

Golden Member

Win-ellende heeft geen dmesg he? Dan zou je eens kunnen kijken waarom het ding 'eruit vliegt' (kooi dicht doen helpt zeker niet?).

Jawel hoor dat heet "Event viewer".

De jongere generatie loopt veel te vaak zijn PIC achterna.

Mocht de oorzaak opslingering zijn a la Application Note 88 dan zou traag schakelen kunnen helpen.
Dus een flinke gate weerstand (10-100 k) en een extra c'tje van 10n van de gate naar de +3.3V.

Reset pin wel (goed) aangesloten?

Als je de schakeling echt hebt zoals je hierboven post, dan kan dat niet het gedrag geven wat je nu ziet. Het feit dat de usb chip onderuit gaat, kan eigenlijk alleen een voltage drop betekenen (die is verder volledig onafhankelijk vd Arduino zelf, geen software involved). Een voltage drop kun je niet veroorzaken met een fet aangesloten zoals getekend.
Maar stel nu dit: je hebt de fet foutief aangesloten, zodanig dat er een geleiding is van 3v3 naar de i/o waar je de "gate" mee stuurt (dat zou dan mogelijk dus niet de gate zijn). Van D naar S is zo'n verbinding via de body diode. Nu trek je jouw i/o naar '0' om uit te schakelen, dan gaat er een dikke stroom van 3v3 die i/o in lopen en trekt daarmee aan de voeding. Suggestie: check de aansluiting van de fet.

@rwk hierboven: TS gebruikt een Arduino, daar zit alles vanzelf al goed :-)

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein