probleem met I2C


"Om het probleem heen werken" heet dat :-)
Een herstart kan lang niet altijd natuurlijk. Je start nl alles opnieuw, ook het initialiseren van variabelen, opgeslagen metingen, communicatie met een host valt ineens weg op onverwachte momenten, display update wordt halverwege afgebroken, etc...

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

Special Member

Op 21 mei 2019 17:51:44 schreef Arco:
Een deadlock is geen geheel vastlopen, de interrupts draaien dan gewoon door... ;)

Daarom moet je nooit zomaar je watchdog updaten vanuit een interrupt op timerbasis.

Maar het kan wel: Als je dat wil doen moet je een handshake met je main loop maken zodat je daar ook een watchdog-functionaliteit hebt.

Een herstart kan lang niet altijd natuurlijk. Je start nl alles opnieuw, ook het initialiseren van variabelen, opgeslagen metingen,

Dat hoeft niet. Je kunt zien dat de reset door de watchdog is veroorzaakt, in dat geval init van vars overslaan...
Ik zie trouwens dat stukje nergens in de errata van de 2580? (alleen een probleem bij gebruik als slave als je de timing verkeerd gebruikt)

[Bericht gewijzigd door Arco op 26 mei 2019 13:25:07 (21%)]

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com
blackdog

Golden Member

Hi luigi_ :-)

Kennis van het i2c protocol heb ik niet veel zoals de programmeurs hier,
maar ik kan je wel vertellen dat je scoop foto's er niet goed uit zien.

De eerst foto van 21 mei lijkt goed, en dan bedoel ik geen rare over en onder shoots.
Maar op deze foto is niet het spannings niveau af te lezen, zoals b.v. 3.3V of 5V.

Wel is zichtbaar dat je Pull-Up weerstanden te hoog zijn in waarde,
de opgaande flank raakt aan de bovenzijnde de neergaande flank, dit is een ongewenste situatie.

Bij je tweede plaatje zie ik dat je 5V voeding gebruikt :-)
Maar wat is die blauwe trace met met de zeer grote ondershoot!!!
Ook hier is zichtbaar dat je Pull-Up weerstanden te laag in waarde zijn.

Ik heb hier maar weinig i2c spul voor handen, dus kan niet zo goed testen voor je.
Zover ik weet, mag je ruim boven de 10mA gaan aan stroom door je weerstanden,
dus 1K als Pull-Uplijkt mij geen probleem on rte zien of je de goede niveau's dan wel haald.

Nog een optie, geen 5V en 3.3V i2c onderdelen door elkaar geruikt?
Een van de i2C onderdelen is misschien niet goed meer?

Wat mij betreft, eerst er voor zorgen dat je i2c signalen en spik en span uit zien, en dan pas aan software oplossingen denken.
Een Logicanalyzer is eigenlijk een "soort" Spice, regelmatig liegt het recht in je gezicht. :-)
Het laat je een "opgeleukte" weergave zien van hoe je databus er uit ziet.

Gebruik de Logicanalyzer waar het zinnig is, dat is het hier zeker niet,
je gaat de bus nog meer belasten bij een bus die er toch al niet optimaal uit ziet.
Een scoop probe op de 1:10 stand en een goed gekozen aardpunt voor de probe is je vriend bij het oplossen van dit probleem. :-)

Als het signaal er uiteindelijk goed uit ziet, en de storing treed nog steeds op, dan naar de software kijken.

Mijn 2 cent.

Groet,
Bram

Waarheden zijn "Illusies waarvan men vergeten is dat het illusies zijn"

De min/max stroom hangt van de gebruikte mode af: standard, fast mode, fast mode+, hi-speed of ultra fast...

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Op 26 mei 2019 15:57:30 schreef blackdog:
Wel is zichtbaar dat je Pull-Up weerstanden te hoog zijn in waarde,
de opgaande flank raakt aan de bovenzijnde de neergaande flank, dit is een ongewenste situatie.

Hier ben ik het niet mee eens. Als de clock periode rond de 2-3 tau van de RC van de bus is, dan werkt het prima. Als je googled op "i2c scope trace" bij "images" dan zie je talloze traces die volgens jou niet goed zijn (alsmede enkele die volgens jou wel goed zijn).

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

In fast mode (zoals op scoopbeeld) moet Thigh > 0.6uS zijn, dat haalt 'ie niet. (wordt als high gezien als level boven 70% is)
Officieel voldoet dat beeld dus niet aan de i2c specs, pull-ups zouden zwaarder moeten zijn. (of busload lichter)

De scoop probe kan ook nog enige invloed op het beeld hebben door de extra belasting.

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Op 26 mei 2019 12:09:06 schreef flipflop:
"Om het probleem heen werken" heet dat :-)

idd de juiste vertaling vertaling van work arround

Op 26 mei 2019 12:09:06 schreef flipflop:
Een herstart kan lang niet altijd natuurlijk. Je start nl alles opnieuw, ook het initialiseren van variabelen, opgeslagen metingen, communicatie met een host valt ineens weg op onverwachte momenten, display update wordt halverwege afgebroken, etc...

Herstart geen probleem, na een herstart gaat de MCU direct alle data terug ophalen in de PLC, dus geen dataverlies

Op 26 mei 2019 16:09:54 schreef Arco:
De min/max stroom hangt van de gebruikte mode af: standard, fast mode, fast mode+, hi-speed of ultra fast...

idd voor 100Khz is 4K7 ok

Er is sowieso geen dataverlies, want de ram inhoud blijft na een reset gewoon bewaard en verandert niet.
En 4k7 is hoog voor een bus met 4 ic's eraan, ook op 100kHz...

[Bericht gewijzigd door Arco op 26 mei 2019 20:21:55 (24%)]

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Op 26 mei 2019 15:57:30 schreef blackdog:
Gebruik de Logicanalyzer waar het zinnig is, dat is het hier zeker niet,
je gaat de bus nog meer belasten bij een bus die er toch al niet optimaal uit ziet.

Nochtans 'ziet' een Logicanalyzer de signalen zoals de MCU ze ziet en kun je ook een heleboel data loggen. Dus wel een handig ding

Nochtans 'ziet' een Logicanalyzer de signalen zoals de MCU ze ziet

Da's niet altijd waar. De CPU inputs hebben hi/lo levels van 70%/30% terwijl een LA vaak TTL is. (ziet dus heel wat anders)
Een LA is wel ideaal om SPI en I2C messages 'uit te vlooien'. Voor het signaal zelf is een scoop beter (of een LA met analoge inputs)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Tja, de MCU heeft toch ook TTL level inputs, of bestaan er verschillende definities voor TTL?

Een i2c i/o heeft gespecificeerde 70/30% levels, geen TTL. (dus ook de peripheral in de MCU)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

ok, maar de I2C slave IO expander MCP23017 werkt dan toch met TTL inputs.
die ziet de data dan toch zoals een LA ze ziet?

De enige inputs die TTL zijn, zijn de adres inputs (A0, A1, A2). De rest is CMOS/ST. (in dit geval 80/20%)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Ik ga er verder mijn hoofd niet meer over breken hoe het komt dat na (een) dag(en) de zaak vastloopt want dat kan eindeloos duren.
Ik heb er een mooie workarround voor gevonden en voor mij is de zaak opgelost.
Ook de errata over de MSSP van de 18F258 (eigenlijk dezelde architectuur als een 18F2580 maar met minder ram) heeft mij die richting ingestuurd.
Allemaal bedankt voor het meedenken

Je kunt een errata van een compleet andere processor niet betrekken op deze, heeft er niets me te doen...

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Zoals ik al zei: probleem opgelost!

Jouw 'kludge' heeft niets met die errata te maken.
De i2c uit en aanzetten lost ogenschijnlijk het probleem op omdat de hele zaak opnieuw opstart. Met echt probleemoplossen heeft het niets te maken...

(als je tv een paar keer per dag raar doet, en je moet hem uit en aan zetten, accepteer je dat toch ook niet als 'oplossing'?)
Ik heb met i2c (op heel veel verschillende MCU's) nog nooit problemen gehad. Als je de datasheet maar goed volgt...

[Bericht gewijzigd door Arco op 26 mei 2019 22:07:33 (15%)]

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com
blackdog

Golden Member

Hi,

Hoe je er ook tegenaan kijkt, de pulssignalen moeten er als je er naar kijkt met een 1:10 probe op de scoop goed uit zien.
Is dit niet zo, dan heb je kans dat het op termijn toch mis gaat, pulsen die maar ter nauwer nood het vereisde 70% voedings niveau halen kan ik niet goed vinden.
De 30% voor het laag niveau van de gebruikte voedingspanning is meestal geen probleem als je de massa aansluitng goed geregeld hebt.

Wat ik hier zag aan signaal kwaliteit van het scoop plaatje kan ik niet goed noemen.
Er van uit gaan dat de robuustheid van het i2c protocol het wel oplost vind ik een verkeert uitgangs punt.

Mijn uitgangspunt is dat het i2C signaal er goed moet uit zien, bij 100KHz kan het zelfs met korte draden met 10K Pull-ups die vaak op een sensor aanwezig zijn.
Maar dat is voor een normale situaties voor storingsvrij gebruik gewoon niet voldoende.
Sommige van jullie willen de Pull-Ups zo hoog mogelijk hebben, wat begrijpelijk is vanwege het stroomverbruikt.
Zoals altijd gaat bij mij de stabiliteit voor, voor jullie? mogen jullie zelf beslissen :-)

rew
Wat je allemaal met Google vind wat gemeten signalen betreft, zegt mij heel veel over de gene die deze metingen gedaan heeft.
In principie vertrouw ik maar een paar mensen wat foto's van metingen betreft, waarvan Jim Williams er één van is.
Als het goed is begrijp je wat ik bedoel. :-)

Voor de gene die het niet weten, hele dikke traces omdat er gemeten is met max bandbreedte en metingen aan blok signalen met grote over en ondershoot zijn de norm op het Internet, zo hoort het dus niet in mijn ogen.

De opmerking over de Logic-analyzer geeft mooi aan dat het waarschijnlijk niet goed begrepen is.
Dit instrument geeft je mooie blokgolven op je apparaat maar wat je het op ziet ziet,
maar dat is niet het signaal, het is een geperfectioneerde weergave.
Ik heb niets tegen Logic-Analyzers, zoals met alle meetinstrumenten denk na als je ze aansluit, ze belasten het circuit. :-)

Door het aansluiten van de Logic analyzer kan het b.v. ook net weer goed gaan of net niet...
Dus zorg er eerst voor, dat je digitale signalen er goed uitzien, zodat ze ook later er geen problemen optreden door b.v. temperatuur wisselingen en dat de Logic-analyzer niet tegen je liegt omdat er voldoende stroom is om de ingangsimpedantie van de Logic-analyzer aan te sturen.

Oja, de drie standen van de bus wat snelheid betreft, geven de stroom aan wat je als basis kan zien dat nodig is voor de bus bij die snelheid bij een bepaalde bus capaciteit en je natuurlijk de weerstandswaarden die uit deze stroom volgen.
In principe bepaald zover ik weet, de Pull-up weerstand de stroom en niet de snelheid van het protocol.
De snelheid verlang een minimale stroom om met max. paracitaire capaciteit(400pF schijnt de norm te zijn) goed te werken.

De transistor in het i2c device (SDA en SCL aansluiting) is meestal een MOSfet die hard geschakeld wordt, zover ik weet is dit geen stroombron.

Ik ben op het ogenblik niet bij machte om nette scoop metingen te laten zien van het project waar ik op het ogenblik mee bezig ben.
Dat is een Adafruit Feather M0 met wat i2c sensoren en scherm, ik ben namelijk vergeten een scoop probe vergeten mee te nemen...
Anders had ik hier wat plaatjes van mijn i2c bus laten zien.

Zoals altijd is er altijd een "Error Budget"
Hoeveel devices gaan er op de bus
Welke snelheid gaat er gebruikt worden
Hoeveel parasitaire capaciteiten spelen er mee
Hoeveel energie mag ik verbruiken
Is er een device op de bus die misschien maar weinig stroom kan syncen
Zijn alle devices 3.3v of 5V geshikt?
Vullen jullie het zelf verder aan :-)

En hier een plaatje uit een Philips/NXP document dat een deel van de specificaties weergeeft wat stromen en snelheid betreft.

Gegroet,
Bram

Waarheden zijn "Illusies waarvan men vergeten is dat het illusies zijn"

daar staat dus dat tot fastmodeplus de sink stroom 3mA moet/mag bedragen. 1500 ohm bij 5V is dus een te lage weerstand. 1800 is als de voeding toevallig rond de max van de range zit ook net te veel (te lage weerstand, te veel stroom).

Met een bus capaciteit van 400pF en een 2k pullup krijg je een RC van 800ns. het klok signaal is bij fastmode 2.5 µs voor een cyclus. De hoogperiode is dus 1.25 microseconde, slechts anderhalf tau.

[Bericht gewijzigd door rew op 27 mei 2019 09:16:25 (15%)]

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
blackdog

Golden Member

Hi rew, :-)

Ik zie het op deze manier, er is minimaal 3mA stroom nodig en gebruik je geen stroombegrensings weerstanden dan is dit 6mA.
Ik zie trouwens maar weinig mensen die stroombegrensweerstanden aan de slave units toepassen of natuurlijk de master.

Die 6mA kan je dus gewoon toepassen zonder deze begrensings weerstanden om te voldoen aan het minimale "laag niveau" Vol van 0,6V.
De stromen die vermeld staan zijn de minimale stromen.
De opmerking van jou dat 1K5 een te lage waarde zou zijn klopt volgens mij dus niet, die zit dan bij 5V mooi onder de minimale waarde die nodig is.

Mijn voorlopige conclusie is dat er over het algemeen te "hoge" Pull-Up weerstandswaarde gebruikt worden bij i2c.
Ik ben nog niet helemaal klaar met mijn onderzoek over het i2c protocol, ik vind de hysteresis van de Schmitt tigger ingang wel wat laag gekozen.
Dit is gespecificeert op 0,05Vdd dat is 250mV bij 5V en en 165mV bij 3.3V.
Dit is misschien de rede van de soms vreemde effecten die ik heb met het i2c protocol, misschien ten gevolgen van opgepikte stoorsignalen...
Ik kan dit Schmitt tigger niveau, nog niet goed rijmen met de logische niveaus van 30 en 70%
Ik zal de logische niveaus eens uittekenen op een stukje papier om te kijken of dit mij meer inzicht gaat opleveren.

Verder heb ik een aantal i2c devices bekeken wat betreft de max. stroom die de open Collector of Drain mag trekken,
dat is meestal nogal onduidelijk, meestal is het zoiets als "volgt de i2c specificaties" voor die en die snelheden.
Hoe zie jij dat?

Groet,
Bram

Waarheden zijn "Illusies waarvan men vergeten is dat het illusies zijn"

Het is inderdaad een beetje vreemd omschreven.
Ik denk dat de drempels bij 30/70% liggen, en het actuele schakelpunt daar ergens tussen.
Als bij 50% de pin hoog wordt, dan wordt 'ie bij 50%-0.05Vdd weer laag. Heeft dus niets met de eigenlijke drempels te maken.

De busbelasting wordt op 400pF max. per deelnemer gegeven, in dit geval (4 ic's) dus 1600pF.
(als je het scoopplaatje bekijkt is de belasting in werkelijkheid veel lager...)

Bij de fast-mode staat dat een 'hoog' puls minimaal 0.6uS boven de 70% moet zitten.

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Op 27 mei 2019 16:27:14 schreef blackdog:
Ik zie het op deze manier, er is minimaal 3mA stroom nodig en gebruik je geen stroombegrensings weerstanden dan is dit 6mA.

De spec is dat iedere slave het LOW niveau van 0.4V moet kunnen halen als er 3mA loopt. Als jij een 1500 Ohm pullup naar 5V monteert, dan loopt daar 3.07 mA en zegt de spec helemaal NIETS over wat de slave wel en niet moet doen. ("rook" behoort tot de geldige opties).

De spec zegt een output level van 0.4V en een input level van 0.6V. Dit geeft 0.2V "noise margin" om evt. groundbounce of andere stoorbronnen te kunnen tolereren.

Natuurlijk zijn moderne outputs in staat om makkelijk 20mA te sinken en is het geen probleem om een wat heftigere pullup te monteren. Maar volgens de regels zou het met een "max 3mA" chip ook moeten werken.

Op 27 mei 2019 17:04:05 schreef Arco:
De busbelasting wordt op 400pF max. per deelnemer gegeven, in dit geval (4 ic's) dus 1600pF.

Dat lijkt me stug. Volgens mij gaat het met dat soort getallen dan heel snel fout. Mijn PC (PCs staan niet bekend om "veel I2C peripherals" toch?) heef tien i2C targets. Zou er dan 10*400pF = 4nF aan capaciteit op 1 bus zitten, dan zit je met een 2k pullup aan een RC van 8 microseconden. Dan werkt niets meer.

Ik denk dat het echt 400pF per hele-bus is. Zie:
https://www.allaboutcircuits.com/technical-articles/i2c-desi...esistance/ onder het kopje Capacitance

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/