probleem met I2C

EricP

mét CE

Dus mijn hypothese is dat er tussen de slaves en de master een verschil van mening ontstaat over hoeveel clockpulsen er geweest zijn.

Dat zie ik niet zomaar, rew. Als we aannemen dat de slaves geen clock stretching doen, dan wordt de clock dus alleen door de master laag getrokken. Als die dus laag blijft, dan zit het probleem hoe dan ook in de master. Als een slave out-of-sync is om welke reden dan ook, dan klopt er wellicht iets niet in de response, maar het kan mi. niet verklaren waarom een SCL laag blijft.

Als ik TS zo lees, dan is het ergens een brak stuk implementatie (hardware of software) wat zo nu en dan de mist in gaat. Dat kan veroorzaakt worden door een bepaalde state waar net een interrupt in optreedt. Of nou juist niet.
Het kan ook een hardware bug zijn. Of zoals Arco al opmerkte: een brakke implementatie in hardware waardoor de boel op z'n b*k gaat als je er niet heel lief in software mee om gaat (bijvoorbeeld een shift-out register zonder shadow register zodat wanneer je daar te vroeg in schrijft je shift-out stuk gemaakt wordt).

Wat je ermee moet? Nou ja, de source van de software implementatie eens goed bekijken (is die beschikbaar?), eens heel goed kijken dat de datasheet zegt over hardware I[sup2][/sup]C. En dan eens kijken of dat matched.
De delays waar Arco het over heeft... Het is natuurlijk wel een 'pic-ding-waardige oplossing'. Maar ja, je moet wel eens wat...
In die context zou het verhogen van de bussnelheid ook wel eens een oplossing kunnen zijn: als je wat plat schrijft tijdens een shift-out en dat is hardware, dan is die mogelijk al voorbij als je de bus snelheid wat op schroeft... Aangenomen dat dat gewoon de setting in een divider is en de software daar verder geen weet van heeft.

EricP

mét CE

Op 22 mei 2019 10:00:12 schreef Arco:
Nogmaals: Dat werkt niet
Als de processor gedeadlocked is lopen de interrupts (en die timer) dus gewoon door!

Dan werkt dat toch prima? Die timer loopt door, je komt niet meer in je main om 'm te resetten, dus ergens overflowed het ding en genereert een interrupt. Of mis ik wat?

Arco

Special Member

Op die manier wel inderdaad... ;)
Met watchdog testen is ook simpel: bij een watchdog reset is het RCON:TO bit 0.

Heb even gekeken. Voor een bus met 4 users (master en 3 slaves) moet de pull-up bij 5v tussen 1k5 en 2k2 liggen in fast-mode (400kHz)
PIC implementatie van i2c is niks mis mee, ligt meestal aan de slave i.c.m. brakke libraries. Slave geeft 't op als er wat 'vreemds' binnenkomt.
(of de software test/reset de i2c errorflags niet, dan loopt de boel ook vast natuurlijk)

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

Special Member

Ik vind dit er toch stukken beter uitzien dan die dennennaalden van de TS. Dit is op 100KHz.

zo belabbert ziet een i2c bus er eigenlijk altijd wel uit.

Dus @rew, waarom heb ik wel een goed signaal dan?

Als je haar maar goed zit, GROETEN LAMBIEK.
Arco

Special Member

Een LA maakt er digitale signalen van (ingangen zijn vaak S/T), de eerste foto is een analoog signaal zonder bewerking...

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

Ja er is duidelijk verschil tussen een logic analyser en een oscilloscoopbeeld

Lambiek

Special Member

Dat maakt inderdaad wel iets uit ja.

Als je haar maar goed zit, GROETEN LAMBIEK.

Ik ga even nog wat nader in op mijn project:
Ik verstuur en ontvang ook CANbus berichten (van een PLC) via de USART (CANmodule van de PIC).
Als een CANbus bericht binnenkomt veroorzaakt dit een interrupt.
MSSP voor de I2C wordt hierdoor niet verstoord, want deze draait autonoom op zich.
PS: PIC is al enkele uren aan het draaien met 'heavy load' op I2C zonder vastlopen, ik wacht af

[Bericht gewijzigd door luigi_ op woensdag 22 mei 2019 20:42:40 (96%)

Arco

Special Member

Als je zeker wilt weten of de bus vrij is, moet je de statusbits in SSPSTAT en SSPCON2 testen voor iedere acie...

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

OK misschien een goede aanvulling
Volgens de datasheet zou ik volgende bits kunnen gebruiken:

SSPCON
bit 6 ACKSTAT: Acknowledge Status bit (Master Transmit mode only)
1 = Acknowledge was not received from slave
0 = Acknowledge was received from slave
bit 5 ACKDT: Acknowledge Data bit (Master Receive mode only)(1)
1 = Not Acknowledge
0 = Acknowledge

SSPSTAT
bit 0 BF: Buffer Full Status bit
In Receive mode:
1 = Receive complete, SSPBUF is full
0 = Receive is not complete, SSPBUF is empty
In Transmit mode:
1 = Data transmit in progress (does not include the ACK and Stop bits),
SSPBUF is full
0 = Data transmit complete (does not include the ACK and Stop bits),
SSPBUF is empty

Arco

Special Member

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

ok, dat was mij even ontsnapt
Ik heb volgende instructie bekomen:

Dim BusBusy as byte
BusBusy= SSPCON2 & %00011111 | SSPSTAT.2

Als BusBusy= 0 dan pas voer ik de Hbusout of Hbusin uit.

EricP

mét CE

Op 22 mei 2019 13:05:56 schreef Arco:
Als je zeker wilt weten of de bus vrij is, moet je de statusbits in SSPSTAT en SSPCON2 testen voor iedere acie...

En eh... als je dat nou niet doet... Dan hangt de boel??? Kijk, dat je wat onzin uit stuurt, dat snap ik. Je kunt er niet meer uit duwen dan de snelheid toestaat. Maar dat je de hardware op zou knopen... Duidt toch op eh... toch wel iets mis met die implementatie (geeft niet hoor, komt vaker voor... maar om de een of andere reden sta ik er niet van te kijken).

ligt meestal aan de slave i.c.m. brakke libraries. Slave geeft 't op als er wat 'vreemds' binnenkomt.
(of de software test/reset de i2c errorflags niet, dan loopt de boel ook vast natuurlijk)

Als een slave het opgeeft, dan verklaart dat niet waarom een master (daar lijkt het nog steeds op...) de SCL laag houdt. Idem zou het al dan niet testen van een errorflag zoiets moeten kunnen veroorzaken.
Elke beetje implementatie heeft iets van een shadow register: je jast het in het output holding register. Als de hardware zover is, dan doet die zelf ff een copy naar een output shift register (waar je vanaf de software kant niet eens bij hoeft te kunnen) en schuift eens wat. Die copy is atomair: als je er te snel data in frut, dan mis je gewoon een byte (en daar zal vast wel wat nerveus van worden). Maar het maakt voor het functioneren van de bus niet uit...

Ik kan me wel voorstellen als een slave de weg kwijt raakt en die wel gebruikt maakt van clock stretching dat er zoiets gebeurt. Maar daar kom je dan ook alleen nog maar uit door de slave te resetten - doorgaans een power cycle.

Zoals ik al eerder opmerkte: als het een timing gevoelig iets is, dan zou het prima zo kunnen zijn dat de bus sneller maken het symptoom niet meer laat optreden. Als dit stabiel lijkt te zijn, dan zou je ter leering ende vermaeck de boel eens 'langzaam' kunnen zetten en kijken of het dan wel stuk gaat.

Nou is basic al heel lang geleden (80-er jaren ofzo), maar eh... die AND en OR zo bij elkaar... Op het oog is het spannend zonder haakjes (wat absoluut niet betekent dat het onjuist is hoor)

Arco

Special Member

Het niet meer communiceren is het resultaat van een optredende error, en libraries die daar niet goed op reageren.
Meestal sturen die plomp de gewenste data uit, zonder te testen of er problemen zijn. Bij een error stopt de communicatie.
De betreffende i2c functie in de library stuurt data, en gaat dan in een eindeloze loop pollen tot er een 'gereed' bit wordt geset, wat nooit meer gebeurt.

Er wordt gewoon niet op dat soort toestanden getest. De libraries van MikroE hadden dat ook, heb er toen zelf maar een gemaakt.
Bij navraag bij MikroE zeiden ze het zo te doen om het eenvoudig te houden voor de programmeur, omdat het anders voor sommigen te ingewikkeld werd...
(waar ik het uiteraard niet mee eens was)

And/Or zonder haakjes ben ik ook geen voorstander van, niet alle compilers behandelen dat hetzelfde.
(sommige doen eerst de and of de or, anderen behandelen zo'n constructie van rechts naar links of andersom)

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

Oef, ik ben er eindelijk uit en wou mijn oplossing nog even meegeven.
Het is beter te voorkomen dan te genezen heb ik altijd geleerd, maar in dit geval niet.
Na het vinden van een errata van de MSSP heb ik moeten vaststellen dat het probleem niet voorkomen kan worden, maar wel omzeild.

This failure has been observed only under two circumstances:
• A Repeated START occurs within the frame of a data or address byte.
The unexpected START condition may be erroneously interpreted
as a data bit, provided that the
required conditions for setup and hold times are met.
• A Repeated START condition occurs
between two back-to-back slave address
matches in the same Slave, with the R/W bit
set to Read (= 1) in both cases. (This circumstance
is regarded as being unlikely in
normal operation.)

Work around
A time-out routine should be used to monitor the
module's operation. The timer is enabled upon the
receipt of a valid START condition; if a time-out
occurs, the module is reset. The length of the timeout
period will vary from application to application,
and will need to be determined by the user.
Two methods are suggested to reset the module:
1. Change the mode of the module to something
other than the desired mode by changing
the settings of bits SSPM3:SSPM0
(SSPCON1<3:0>); then, change the bits
back to desired configuration.
2. Disable the module by clearing the SSPEN
bit (SSPCON1<5>); then, re-enable the
module by setting the bit.
Other methods may be available.

zo is het uiteindelijk geworden dan:
WDT enabled en aan het einde van de code clear ik telkens de WDT

de eerste instructies in mijn code zijn:
SSPCON1.5=0 (Disable MSSP)
PORTC.3 set als output
PORTC.4 set als output
SSPCON1.5=1 (Enable MSSP)

Als de WDT een overflow krijgt start de code vanvoren af aan

"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

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.

Arco

Special Member

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 zondag 26 mei 2019 13:25:07 (21%)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: 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

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
Arco

Special Member

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" - hard-, firm-, en software ontwikkeling: 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/
Arco

Special Member

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" - hard-, firm-, en software ontwikkeling: 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

Arco

Special Member

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 zondag 26 mei 2019 20:21:55 (24%)

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