I2C lock-up

j s jarin.hw na gmail.com
Pondělí Srpen 20 15:50:57 CEST 2012


Odpoviem ti naraz, nech to nie je velmi rozbite.

Ked nastane lock-up, tak sa z neho da vyjst bud power-on-resetom,
alebo tym clockovanim. Oboje nasvedcuje tomu, ze niekde nieco caka na
ACK alebo tak nieco.
Ked sa vyskytol problem, najprv som skusil ten POR, samozrejme
(klasika - pripojim, odpojim). Potom som ale zacal badat trochu
hlbsie, lebo mi to nepripadalo ako dobry sposob ako to osetrit.
Prisiel som na tych 9 clockov na SCK, ktore - zda sa - funguju. Ale
nepaci sa mi to a preto som sa pytal ostatnych, co oni na to.
Ten lock-up robi zrejme displej. Z EEPROMky sa precita kopa dat do RAM
hned na zaciatku, potom sa s nou nerozpravam a iba sa obnovuje
displej. Samozrejme, je moznost, ze vplyvom nejakeho bordelu na
zbernici si EEPROM vylozi data na zbernici ako svoju adresu a zacne
robit neplechu.

Mimochodom, na niecom podobnom som sa spalil pred casom s displejom
BO1602B od Bolymin-u. Cinski kolegovia to urobili tak, ze na svoju
slave adresu (tusim 0x78) reagoval nielen po start bite, ale
kedykolvek v datovej komunikacii. Mal som na zbernici este EEPROM a
ked sa do nej zapisovali (premenlive) data, tak sa to sem-tam zrubalo.
Dost dlho mi trvalo zistit, ze sa to vzdy doondi po zapise bajtu 0x78
do EEPROM a ze to nesuvisi s napajacim napatim, pull-upmi alebo
softwarovou chybou - co bol primarny zdroj podorzenia. Potom som si
experimentalne overil, ze ten displej skratka ACK-uje akykolvek byte
0x78 na zbernici, kedykolvek v ramci komunikacie. Samozrejme, tam
nepomohlo nic ine nez dat displej na separatnu zbernicu a zanadavat si
na rakosnikov.

Ako zistim, ktory slave to drzi? SDA nohy tychto dvoch su od seba
vzdialene asi 5mm.
V datasheete OLED drivera som nenasiel nic podozriveho. Je to SSD1307,
ale ktovie co je skutocne pouzite vnutri, ci to nebude nejaky sikmooky
SSD1307.
Tu resynchrozniaciu robim velmi pomaly, clock ma 10ms, lebo sa mi
nechcelo nastavovat timer a 10ms zakladnu tam uz mam :-)

Mimochodom, okrem tamtoho problemu s tym BO1602B a tymto problemom s
OLED som nikdy nemal s I2C zbernicou nijake vaznejsie problemy, hoci
mam k nej isty druh vnutornej averzie a pouzivam ju len ked je to
skutocne nevyhnutne.



Dňa 20. augusta 2012 15:23, Jan Waclawek <konfera na efton.sk> napísal/a:
>>treba power-on-reset I2C slave
>>zariadeni
>
> [...]
>
>>Ked to
>>nastane, treba jeden az devat krat potahat za SCL drot (vacsinou sa
>>uvolni po prvom clocku). Toto som vlozil aj do I2C inicializacie, pre
>>pripad.
>>
>>Zda sa, ze to funguje
>
>
> No tak treba ten poweron reset alebo netreba?
>
> A ktory z nich to robi? To by malo byt lahke zistit.
>
> A ak Ti niektory (tipujem ten display kontroler) nerozumie, co tak skusit na neho hovorit pooomaaaalsieeee (to aj tomu starsiemu synovi hovorievam, niekedy neskutocne rychlo drmoli a aj ja sa niekedy vo vzajomnej komunikacii s nim zaseknem, aj musim urobit resynchronizaciu) napr. prave v case ked ma ACKnut - vtedy pravdepodobne "nieco robi" a je mozne, ze prave tam je nejaky maly bucik schovany... Datasheet co hovori, mimochodom?
>
>
>>Riesite taketo veci u svojich I2C implementacii? Ak ano, mate este
>>nejake ine postrehy/skusenosti?
>
> I2C je az neskutocne castokrat naimplementovane blbo v hardwari rozneho charakteru, napriek tomu ze by to nemalo byt az take tazke urobit dobre. Inak je to na ten ucel, na ktory to bolo vymyslene, super. Treba samozrejme dodrziavat vsetko, co treba dodrziavat.
>
> Mozno si si vsimol ze som onoho casu mal niekolko emotivnych poznamok na adresu norskych inzinierov, napriklad... :-)
>
>
> wek
>
>
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list


Další informace o konferenci Hw-list