i2c level probleem ?

Voor een slimme meter uitlees project gebruik ik een (3.3 volt voeding) 89LPC52 microcontroller. Deze stuurt via een tweetal 8574 i2c->8 bit parallel interface chips (5 volt) een 2x20 karakter lcd display (eveneens 5 volt) aan. Deze chips zijn geschikt tot 400kHz. Daar voldoe ik aan. I2c bus wordt met 2 pull-ups van 2k2 naar de 5 volt getrokken. Bus lengte is iets van 10 cm.
De beide i/o pinnen voor de i2c zijn gedefinieerd als bi-directional.
Ik maak gebruik van een eigen protocol wat al jaren zijn geschiktheid heeft bewezen (maar wel met 5 volt procoessoren). Dit om de timing in eigen hand te kunnen houden. Het build-in protocol laat ik voor wat het is.

Het gebeurt met enige regelmaat (zeg 1 of 2x per dag ofzo) dat het display verstoord raakt. In de praktijk doet het of helemaal niets meer of het schakelt terug van 2x20 naar 1x20 karakter (default situatie). De microcontroller blijft gewoon doordraaien zoals uit andere indicaties blijkt.

Wat is hier aan de hand ?
Op de scoop zie ik dat de i2c signalen redelijk steil tot 3.3 volt stijgen, dan is er een lag in de vorm van een e-macht om tot 5 volt te komen. Is dat mogelijk een probleem ?
Ooit ergens iets gelezen over het gebruik van een paar kleine c'tjes op de bus (of parallel aan de pull-up. Isd het misschien handig om de definitie van de i2c clock output te veranderen in push-pull output ?

Ik kan je vraag niet echt beantwoorden. Maar ik weet dat er wel iets met C'tjes en kleinere pullup weerstanden was als je afstanden wat langer werden. Ook ging men dan de snelheid wat verlagen.

Misschien moet je gewoon het e.e.a. proberen. Als de hoeken van je i2c blokjes emacht neigingen gaan vertonen duid dat misschien een beetje op een capacitief of inductief probleem. Misschien kun je over elke pullup (aan de voedingskant) een 100nF c'tje zetten. Zodat de spanning daar niet meer kan duiken. Zijn je i2c kabels erg lang?

Weet je zeker dat je 400kHz moet gebruiken? Zet ze eens op 100kHz om te testen en kijk eens of het probleem dan weg blijft. Sowieso is 2k2 op 5V rijkelijk laag, daarmee belast je de bus meer dan met de aanbevolen 4k7.

Daarnaast denk ik dat je een levelshifter moet gebruiken. De I2C lijnen zijn normaal open collector, dus de vraag is of je microcontroller dat ook echt doet, zeker als ie op 3v3 werkt en je de uitgangen naar 5v trekt, dan lijkt mij dat de pinnen van de controller dat niet lekker vinden.

Volgens de specs van die controller is ie geschikt om i/o pinnen op 5 volt te gebruiken. De snelheid heb ik al verlaagd tot circa 300 kHz.
De bus heeft een te verwaarlozen lengte. Iets van 10..12 cm.

Er is een publicatie van Texas Instruments waaruit minimum en maximum waarden voor de pull-up te halen zijn. Dan zit ik met 2k2 nog aan de hoge kant.
Maar die berekeningen lijken geen rekening te houden met een processor op 3.3 volt en een pull-up naar de 5.

Ik heb in elk geval wat werk te doen. De weerstanden toch wat lager maken en eens kijken naar een levelshifter. In een Philips publicatie iets gevonden wat met 1 mosfet per signaal zou werken.
Het verhaal over die C'tjes kon ik niet meer vinden.

Ik heb een 25x25(#) printje met twee mosfetjes (*) voor het "levelshift" gebeuren, als je dat zou willen proberen.

*) en optioneel 2 of 4 pullups
#) of was ie nou kleiner?

Op zondag 1 september 2024 15:52:52 schreef rew:
Ik heb een 25x25(#) printje met twee mosfetjes (*) voor het "levelshift" gebeuren, als je dat zou willen proberen.

*) en optioneel 2 of 4 pullups
#) of was ie nou kleiner?

Bedankt alvast voor je aanbod. Ik heb toevallig net twee mosfetjes bij elkaar gesprokkeld om even wat te proberen. Mocht dit niets worden dan houd ik me aanbevolen. Afmetingen zijn in eerste instantie niet interessant. Eerst zien wat de oplossing is. Losse chips zijn ook te koop maar die waren smd. Daar ben ik inmiddels achter dat die een brug te klein zijn (voor mij dan).

Op zondag 1 september 2024 14:51:58 schreef Leo-Bolier:
Ik heb in elk geval wat werk te doen. De weerstanden toch wat lager maken en eens kijken naar een levelshifter. In een Philips publicatie iets gevonden wat met 1 mosfet per signaal zou werken.

Meer info overzo'n level-shifter: https://learn.sparkfun.com/tutorials/bi-directional-logic-level-conver…

Ik doe dat al jaren in diverse schakelingen met 5V en 3,3V niveaus. Meestal gebruik ik een BSN20 (SMD) of 2N7000 in combinatie met 4k7 weerstanden. Nooit problemen mee gehad.

Dat komt mooi uit

Op zondag 1 september 2024 16:22:49 schreef McAwesome:
[...]

Meer info overzo'n level-shifter: https://learn.sparkfun.com/tutorials/bi-directional-logic-level-conver…

Ik doe dat al jaren in diverse schakelingen met 5V en 3,3V niveaus. Meestal gebruik ik een BSN20 (SMD) of 2N7000 in combinatie met 4k7 weerstanden. Nooit problemen mee gehad.

Ah, ik had al een paar mosfetjes opgescharreld maar deze heb ik ook liggen. Dan neem ik eerst die maar eens.

Even voor de goede orde:

Het lijkt er een beetje op alsof jou 3.3V microcontroller als het signaal hoog moet worden, het EVEN hoog stuurt en dan weer "open drain" maakt. Dit om het normale "langzaam hoog worden doorde pullup" te voorkomen.

De werking van de level shifters met de mosfets is dat de pullups gewoon hun werk doen. de 3.3V kant is 3.3V de 5V kant is 5V en de mosfet staat uit en krijgt 1.7V te verduren. De mosfet moet uitzijn dus de gate hangt aan de 3.3V.

Trekt nu de 3.3V kant de boel laag, dan wordt de gate direct 3.3V hoger dan de source (de 3.3V kant) en gaat de fet aan en de sturende 3.3V microcontroller trekt ook de 5V kant naar nul. So far so good.

Trekt nu de 5V kant de boel laag dan gaat eerst de parasitaire diode in de mosfet in geleiding. De 3.3V kant wordt 0.6V, de gate-source spanning wordt 2.7V, de mosfet gaat "aan" en trekt de 3.3V kant door naar de gestuurde 0V die de slave aan de 5V kant probeert te sturen.

Maar dan nu wat er gebeurt met level shifters in jou situatie: De "stuur even hoog" van jou microcontroller gaat nu door de parasitaire diode de 5V kant naar 2.7V helpen en vanaf daar meot het met de pullup verder naar de 5V.... Precies wat je nu ziet, maar dan net een pietsie minder goed.

Quasi bidirectionele poorten trekken bij 0 -> 1 overgang de pin heel kort hoog met een sterke weerstand en daarna met een zwakke weerstand.
Die zijn ook eigenlijk niet bedoeld voor zaken als i2c...

Op zondag 1 september 2024 11:10:31 schreef Leo-Bolier:
Het gebeurt met enige regelmaat (zeg 1 of 2x per dag ofzo) dat het display verstoord raakt. In de praktijk doet het of helemaal niets meer of het schakelt terug van 2x20 naar 1x20 karakter (default situatie). De microcontroller blijft gewoon doordraaien zoals uit andere indicaties blijkt.

Hangt er niet gewoon een lijntje los aan het display? Reset oid of de WR. Dit soort displays is meestal niet erg nukkig. Wat wel een issue kan zijn is de timing, sommige LCD's zijn behoorlijk traag. Stuur je te snel een nieuw commando of data dan kan het display dit ook als 'onzin' interpreteren. Voeding van LCD en I2C ic's neem ik aan ontkoppeld?

De adreslijnen van de 8574 allemaal aangesloten? Overigens: die 8574 kan niet veel 'sourcen' aangezien de uitgangen ook 'quasi-bidirectioneel zijn'. Zijn de logische niveaus op de uitgangen wel OK voor het display?

Wanneer je het display als 'write only' aanstuurd kun je ook nog proberen die 8574 met 3,3 Volt te voeden. (kan vanaf 2,5 Volt)
De ingangen zijn dan voor zover ik weet niet 5 Volt tolerant maar dat maakt in 'alleen schrijven naar display' niet uit.

Vandaag een mooie dag om alle suggesties uit te proberen.

Voedingen zijn ontkoppeld, geen losse draadjes, adreslijnen van de 8574 zijn hard aangesloten. Displaytje wordt als write-only gebruikt.
Wel een punt zou de (te) snelle opeenvolging van commando's kunnen zijn.
In de initiatie van het display zitten daar een behoorlijke vertraging in maar onder operationele omstandigheden heb ik daar nog niet echt naar gekeken.
Er zit trouwens een periodieke re-init van het display ingebakken in de firmware. Dat zou natuurlijk niet moeten en lijkt hier ook niet te werken.

Ik denk dat ik die bi-dir definitie voor de i2c klok verander in een output of push-pull. En vervolgens die levelshifter ga uitproberen.
Kan wel even duren voor ik weet of het echt werkt. Hij draait nu al weer een etmaal zonder storing...

Redelijk verrassend eerste resultaat van mijn experimenten.
In aanloop naar een levelshifter begonnen met de pull-ups aan de 3.3 volt microcontrollerkant naar de 3.3 volt voeding te leggen in plaats naar 5 volt.
Eerste plaatje: de i2c klok op de 8574 chips voor de aanpassing:

Tweede plaatje: idem maar met de pull-ups naar 3.3 volt

In beide gevallen: 0.1 volt en 0,2 usec per schaaldeel
Het LCD display staat gewoon op 5 volt voeding en blijft werken.
Voor ik verder ga experimenteren laat ik dit maar eens een poosje draaien.
Ga nog wel kijken hoe groot de intervallen tussen diverse commando's zijn en die eventueel nog aanpassen als ze kritisch lijken.

Het eerste plaatje heeft inderdaad wel een heel grote risetime, dat kan problemen geven (zeker i.c.m. bitbangen)
De 89LPC52 vind ik trouwens nergens, klopt dat wel?

Met een TTL-output van 3,3V kun je altijd een TTL-input van 5V aansturen. De TTL logische outputlevels van 3,3V blijven voldoen aan de TTL logische inputlevels van 5V. De nivos tussen 3,3V en 5V worden dan niet benut.

I2c heeft geen TTL ingangen, maar gemodificeerde S/T ingangen...
('0' = < 0.3Vdd, '1' = > 0.7Vdd, hysteresis = 50mV)

Je hebt gelijk.
De officiele I2C spec zegt wel dat legacy devices andere nivo's kunnen hanteren en adviseerd om de betreffende product datasheet te raadplegen.
Mogelijkerwijs kun je met een 3,3V I2C master een 5V I2C slave aansturen.

De officiële specs voor de liefhebber...: :)

i2c_bus_specs_v7.pdf

Tabel 9, Note 1 :)

Heb de V6 specs door de laatste (V7) vervangen, tabel 9 is nu tabel 10 geworden... ;)

Ja net gedaan, dank je. :)

Ik voed nu de 8574 (Philips fabrikaat) met 5 Volt en stuur ze direct aan vanuit de P89LPC952 (3.3 volt voeding). Zojuist op duurtest gezet en kijken wat het doet.
@Arco: de gebruikte chip heet officieel P898LPC952 (of 954, geheugengrootte) van NPX. Het is een 8052 core met de nodige extra's zoals meer poorten, on-board flash, a/d converter, PWM, dubbele datapointer etc.

De originele 100kHz limiet van I2C komt omdat je dan na die e-macht nog een redelijke "hoog-tijd" overhoudt.

Met lagere bus-capaciteit, sterkere pullups enz. kon dat naar 400kHz opgevoerd worden.

Jou signaal heeft een "perfect hoog" tijd van 1 microseconde. Dat is helemaal perfect voor een bus op 400kHz.

Een Atmel stelt vrij strenge eisen aan een i2c signaal. Die eist dat een signaal minimaal 2 clocks hoog is. Op 8MHz moet een clockpuls dus minmaal 250ns duren. Jij hebt hier 4x meer, dat is gewoon prima.

Dit soort verschijnselen heb ik ook weleens gezien doordat ik niet goed rekening hield met de BUSY van de lcd-module. En dit werkte dan met de ene module prima, maar met een andere weer niet.

Mijn project heeft nu ruim 24 uur op duurtest gestaan en is goed blijven werken. Voorlopig denk ik: probleem opgelost.

Het is een kastje wat de P1 poort van mijn Kaifa meter uitleest en pulssignalen van kWh metertjes van de zonnepanelen, de inductieoven en via een leeskopje de led-puls van de Kaifa opvangt.
De gasmeterstand wordt omgevormd naar een aantal verbruikspulsen en samen met de pulssignalen als hierboven doorgestuurd naar mijn datalogger.

Via het toetsenbordje kan een tijdvenster worden ingegeven waarbinnen er een extra 3kW verbruiker mag worden ingeschakeld. Dit o.a. als de coven niet ingebruik is.

De display select toets laat achtereenvolgens de meest interessante registers van de slimme meter zien. Twee grote Led's signaleren of er verbruikt of teruggeleverd wordt.