I2c => Sck à 0

**Toufinet** · 09/02/2007, 16h16

Bonjour à tous,

Voilà la configuration de ma carte :
Le PIC contrôle 2 composants via un bus I2C :
1 PIC 16F887 / maître
1 LM73 ( capteur de température ) / esclave
1 M41T60 ( horloge temps réel ) / esclave

Le programme se lance, et dès que le PIC demande l'heure à la RTC, le programme plante. J'en conclu donc que le problème se situe au niveau de la communication sur le bus I2C.

Après le plantage du programme, j'ai remarqué que le signal d'horloge ( SCK ) est à 0...
Il y a donc un des 3 composants qui force l'horloge à 0.

Le LM73 et le M41T60 étant des esclaves, je suppose que ça NE PEUT PAS être l'un d'eux qui force SCK à 0.

J'en déduit donc que c'est le PIC qui force SCK à 0.

Le problème est que les niveaux logiques de SCK et SDA sont exclusivement gérés par le module MSSP.
Le programme en lui-même ne touche donc jamais directement aux états de SCK et SDA.

Ma question est donc : qui et qu'es-ce qui peut amener SCK à rester bloqué à 0 ?

Je suis débutant sur le bus I2C, merci de vos réponses.

**behemerre** · 09/02/2007, 16h24

Salut,
Tu parles du signal d'horloge ? dans ce cas c'est SCL, à moins que ce ne soit l'acquitement, ACK.
Soit plus clair, et si tu pouvait m'envoyer le prog de ton pic + copie du schèma (si possible) ca serait plus clair !
|-)+

**Toufinet** · 09/02/2007, 16h33

oui, je parle du signal d'horloge.

Voici en partie le programme.
Pour le module MSSP, c'est du bigo-copied

C'est un peu long, dsl.

INIT_MSSP
bank1
bsf TRISC,3 ; SCL en entrée (mis par défaut sur un reset)
bsf TRISC,4 ; SDA en entrée (idem)
movlw B'00000000' ; slew rate control en service, mode I²C
movwf SSPSTAT ; dans SSPSTAT
movlw 0x02 ; valeur de recharge du BRG ( Fréquence interne = 4MHz, SSPADD = FOSC/(FSCL*4)-1 )
movwf SSPADD ; dans registre de recharge
bank0 ; passer banque 0
movlw B'00101000' ; module MSSP en service en mode I²C master
movwf SSPCON ; dans registre de contrôle
return

I2C_start
bank1 ; passer en banque 1
bsf SSPCON2,SEN ; lancer le start-condition
I2C_start2
btfsc SSPCON2,SEN ; start-condition terminé ?
goto I2C_start2 ; non, attendre
bank0 ; oui, repasser en banque 0
return

I2C_adress_write
movlw SLAVE*2 ; charger adresse esclave (b7 à b1) avec b0 = 0
movwf SSPBUF ; lancer l’émission de l’adresse en mode écriture
bank1 ; passer en banque 1
I2C_adress_write2
btfsc SSPSTAT,R_W ; tester si émission terminée
goto I2C_adress_write2 ; non, attendre
bank0 ; oui, repasser banque 0
return

I2C_adress_read
movlw SLAVE*2+1 ; charger adresse esclave (b7 à b1) avec b0 = 1
movwf SSPBUF ; lancer l’émission de l’adresse en mode lecture
bank1 ; passer en banque 1
I2C_adress_read2
btfsc SSPSTAT,R_W ; tester si émission terminée
goto I2C_adress_read2 ; non, attendre
bank0 ; oui, repasser banque 0
return

I2C_check
bank1 ; passer en banque 1
I2C_check2
btfsc SSPCON2,ACKSTAT ; tester ACK reçu
goto I2C_check2 ; pas reçu, traiter erreur
bank0 ; repasser en banque 0
return

I2C_send
movlw OCTET ; charger octet à envoyer
movwf SSPBUF ; lancer l’écriture
bank1 ; passer en banque 1
I2C_send2
btfsc SSPSTAT,R_W ; tester si émission terminée
goto I2C_send2 ; non, attendre
bank0 ; oui, repasser banque 0
return

I2C_read
bank1 ; passer banque 1
bsf SSPCON2,RCEN ; lancer la réception
I2C_read2
btfsc SSPCON2,RCEN ; réception terminée ?
goto I2C_read2 ; non, attendre
bank0 ; repasser banque 0
return

I2C_noack
bank1 ; passer banque 1
bsf SSPCON2,ACKDT ; le bit qui sera envoyé vaudra « 1 »
bsf SSPCON2,ACKEN ; lancer l’acknowledge (= ACKDT = 1 = NOACK)
I2C_noack2
btfsc SSPCON2,ACKEN ; tester si NOACK terminé
goto I2C_noack2 ; non, attendre
bank0 ; repasser banque 0
return

I2C_ack
bank1 ; passer banque 1
bcf SSPCON2,ACKDT ; le bit qui sera envoyé vaudra « 0 »
bsf SSPCON2,ACKEN ; lancer l’acknowledge (= ACKDT = 0 = ACK)
I2C_ack2
btfsc SSPCON2,ACKEN ; tester si ACK terminé
goto I2C_ack2 ; non, attendre
bank0 ; repasser banque 0
return

I2C_stop
bank1 ; passer en banque 1
bsf SSPCON2,PEN ; lancer le stop-condition
I2C_stop2
btfsc SSPCON2,PEN ; stop-condition terminé ?
goto I2C_stop2 ; non, attendre
bank0 ; oui, repasser en banque 0
return
[...]
H_MINU_READ
movlw H_ADDR
movwf SLAVE
movlw H_MINU_REGISTER
movwf OCTET
call I2C_start
call I2C_adress_write
call I2C_check
call I2C_send ; on envoie l'adresse du registre des minutes
call I2C_check
call I2C_start ; restart
call I2C_adress_read
call I2C_check
call I2C_read ; On lit les minutes
movf SSPBUF, 0;
movwf Minutes
call I2C_noack
call I2C_stop
return

Pour le schéma, il n'y a rien à montrer ...
Les SCL de chaque composants sont reliés, idem pour les SDA, avec une pull-up de 10k sur SCL et SDA.

**behemerre** · 09/02/2007, 16h44

salut,
Tu n'aurais pas un peu forcé sur les pull-up, 4,7k suffit

a+

A voir en vidéo sur Futura · Aujourd'hui

**Toufinet** · 09/02/2007, 16h51

J'ai suivit la datasheet.

Ceci dit, c'est pas ça qui force SCL à 0 ...

**freepicbasic** · 09/02/2007, 17h08

Tu utilise des boucles d'attentes bloquantes !
Cela a pour conséquence de planter le prog si l'I2C ne répond plus.

Code:

I2C_start2
btfsc SSPCON2,SEN ; start-condition terminé ?
goto I2C_start2 ; non, attendre

un "Time out" serait préférable.

Pour le moment il faut debogguer
Méthodes de déboguage;
Il faudrait mettre un système de traçage pour déterminer ou le prog s'arrète.
A defaut de port serie, des leds sur un port peuvent faire l'affaire, a défaut de port I/O dispo , une valeur mémorisée en Eeprom data permettra de voir le chiffre de progression avec le programmateur

De ce genre là ;
exemple:

Code:

movlw 0 
call WriteEeprom

call I2C_start
movlw 1 
call WriteEeprom

call I2C_adress_write
movlw 2 
call WriteEeprom

call I2C_check
movlw 3 
call WriteEeprom

call I2C_send ; on envoie l'adresse du registre des minutes
movlw 4 
call WriteEeprom

call I2C_check
movlw 5 
call WriteEeprom

call I2C_start ; restart
movlw 6 
call WriteEeprom

etc ...

**behemerre** · 09/02/2007, 17h10

Désolé, j'ai posté ma réponse dans la mauvais question, merci de supprimer ce message !
Encore désolé

**Toufinet** · 09/02/2007, 17h19

ok freepic, je revient avec l'endroit précis du plantage.

Merci.

**Toufinet** · 09/02/2007, 18h09

Ca plante sur I2C_Check ...

Comme si les slave ne répondaient pas ( j'ai testé pour les 2 ) .. pourtant l'adresse hardware est bonne

**freepicbasic** · 09/02/2007, 18h13

SSPADD = FOSC/(FSCL*4)-1 )

Quelle est la valeur de SSPADD ?
La doc dit que la vitesse en baud est
Fosc/ (4 * (SSPADD+1)

Pour environ 100Khz
4 000 000 / 400 000 = 10
Ce qui donnerai un peu moins de 100Khz

Donc 10 pour un I2C standard

**freepicbasic** · 09/02/2007, 18h16

Ca plante sur I2C_Check ...

Comme si les slave ne répondaient pas ( j'ai testé pour les 2 ) .. pourtant l'adresse hardware est bonne

Oui Ok!

Verifier le cablage data et clock .
verifier si la pull up est présente aussi , surtout sur le data.

**Toufinet** · 09/02/2007, 18h32

J'ai essayé avec SSPAD=10 ( 100KHz ), mais c'est tout pareil

J'ai vérifié 100 fois le circuit, tout est ok ... je vais pleurer

**freepicbasic** · 09/02/2007, 18h38

met une petite tempo a la place du check .
Et essai comme ça voir si le reste passe et si ça lit correctement !

Essai de valeur supérieur de SSADD

**RISC** · 09/02/2007, 20h50

Toufinet,

Comme 50% des PB I2C sont dus au schéma électronique, peux-tu confirmer :

1/ As-tu mis une résistance de rappel sur SDA ET SCLK ?
2/ Quelle valeur ont ces résistances ?
3/ Pourrais-tu poster ton schéma ?

A+

I2c => Sck à 0

I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Re : I2c => Sck à 0

Discussions similaires

I2c

comparaison CAN I2C

i2c

Interruption I2C

I2c