Bus SPI en esclave...

[invite8f8ffe44]

Bonjour à tous,

J'ai un gros problème...
Cela fait un peu plus d'une semaine que je tente de mettre en oeuvre une communication par bus SPI entre deux PIC (le 24HJ12GP201 : le maître, et le 24HJ12GP202 : l'esclave), mais je n'y arrive toujours pas.

Afin de trouver là où mon erreur se trouvait, j'ai finit par utiliser une mémoire EEPROM de microchip (25AA1024). J'ai réussi à établir la communication. Donc, du côté du maître, il ne semble pas y avoir de problème. En revanche, je n'arrive pas à communiquer avec mon PIC esclave. Pourtant, il semble que je l'ai bien configuré (MSTEN = 0, SMP = 0...). De plus, je n'arrive pas à rentrer dans l'interruption que j'ai créer pour l'esclave...

Quelqu'un serait-il ce qui ne va pas?

Voici le code que j'ai mis en place pour mon EEPROM:


/****************************** ****************************** *****/
/* Nom du fichier : Main.c */
/* Date de création : 16 avril 2008 */
/****************************** ****************************** *****/

#include "Gateway.h"

/****************************** ****************************** **********/

#define CS _LATB9

word i = 0;
int a = 0;
int b = 0;
int Freq = 6;
char MIPS = 24;
byte ReponseSPI = 0;
char Tab[16] = "0123456789ABCDEF";
byte VarTemp = 0;
byte Message = 0;


void InitPort(void)
{
IOpin8 = 8; // Patte 8 du PIC --> SCK1OUT (SPI1 Clock Output)
IOpin10 = 7; // Patte10 du PIC --> SDO1 (SPI1 Data Output)
IOpin11 = 8; // Patte11 du PIC --> SDI1 (SPI1 Data Input)
IOpin12 = 9; // Patte12 du PIC --> SS1OUT (SPI1 Slave Select Output)
_NSTDIS = 0;
PORTB = 0;
TRISB = 0x0100;
AD1PCFGL= 0x003F;
}


void InitSPI(void)
{
SPI1STAT = 0x0000;

_SPIROV = 0;
SPI1CON1bits.DISSCK = 0;
SPI1CON1bits.DISSDO = 0;
SPI1CON1bits.MODE16 = 0;
SPI1CON1bits.SMP = 1;
SPI1CON1bits.CKE = 1;
SPI1CON1bits.SSEN = 0;
SPI1CON1bits.CKP = 0;
SPI1CON1bits.MSTEN = 1;
SPI1CON1bits.SPRE = 5;
SPI1CON1bits.PPRE = 2;

SPI1CON2bits.FRMEN = 0;
SPI1STATbits.SPIEN = 1;
}


int main(void)
{
InitUC();
while(1)
{
_SPIROV = 0;
CS = 0;
SPI1BUF = 0xAB;
while(!_SPIRBF);
VarTemp = SPI1BUF;
while(_SPITBF);
_SPIROV = 0;
SPI1BUF = 0x99;
while(!_SPIRBF);
VarTemp = SPI1BUF;
while(_SPITBF);
_SPIROV = 0;
SPI1BUF = 0x99;
while(!_SPIRBF);
VarTemp = SPI1BUF;
while(_SPITBF);
_SPIROV = 0;
SPI1BUF = 0x99;
while(!_SPIRBF);
VarTemp = SPI1BUF;
while(_SPITBF);
_SPIROV = 0;
SPI1BUF = 0x00;
while(!_SPIRBF);
Message = SPI1BUF;
while(_SPITBF);
CS = 1;
}
return 1;
}


Cordialement

Crepuscule3
-----

[invite8f8ffe44]

Personne n'aurait une petite idée?

[RISC]

Salut,

Je ne vois pas plein de choses dans le fichier que tu montres...Pourrais tu Zipper tout ton projet (le répertoire avec tous les fichiers?)

a/ Programmation des bits de configuration ?
b/ déclaration du type de PIC utilisé
c/ initialisation des interruptions SPI
d/ routine de traitement de l'interruption

Problème d'interruption
Niveaux de priorité : au reset les périphériques des familles 16 bits (PIC24 / dsPIC) sont tous au niveau de priorité 4.
Le main est au niveau 0 (registre SRL).

a/ Il suffit donc comme dans un micro classique de :
* nettoyer le flag d'interruption de celle(s) qui t'intéresse(nt) --> registre IFS0 pour le SPI
* autoriser leur flag d'interruption individuelle (registre IFC0 pour le SPI)

b/ Il faut bien sûr qu'il y ait une demande d'interruption

c/ Nettoyer le flag d'interruption (dans IFS0) dans la routine de traitement de l'interruption

a+

[invite8f8ffe44]

Salut!

Merci beaucoup pour ton aide, je ne trouve décidément pas ce qui ne va pas. Ca marche bien tant que je n'utilise que le maitre mais dès que je mets l'esclave la dedans... c'est la merde! De plus, je cherche sur internet des exemples de codes, mais personne ne semble utiliser l'esclave de cette façon... tout du moins je ne trouve rien de ce côté.
Je joints à ce message les projets de l'esclave et du maitre. Si quelqu'un trouve ce qui ne va pas... se serait top!

Cordialement

Crepuscule3

[A voir en vidéo sur Futura]

[RISC]

Salut,

J'ai commencé à regarder le code de l'exclave et je pense avoir détecté un PB au niveau de l'initialisation.

Pour pouvoir utiliser la fonction SPI, il faut initialiser le bloc PPS (Peripheral Pin Select).
Pour pouvoir changer le bloc PPS, il faut impérativement exécuter la séquence unlockIO() et quand la programmation des broches est finie, il faut exécuter la séquence lockIO().
Tout cela est expliqué en détails dans la section 30 du Family Reference Manual (paragraphe 30.4.4.1 et exemple 3-2) : http://ww1.microchip.com/downloads/e...Doc/70234A.pdf

Il est recommandé d'utiliser les fonctions _builtin_write_OSCONL et _builtin_write_OSCONH.

N'oublie pas non plus si ces broches sont multiplexées avec des fonctions analogiques de les déclarer en digital...

a+

[invite8f8ffe44]

Bonjour,

merci beaucoup pour ton aide. Il est vrai que je n'avais encore pas vu ce registre de blocage. Cependant, les pins sont par défaut inscriptible, donc il ne devrait pas y avoir de soucis même sans jouer sur le registre OSCCON.
J'ai l'ai cependant réinitialisé pour voir, mais le problème est toujours le même.
Par ailleurs, tu me parlais de déclarer mes pins en digital et non en analogique... c'était déjà fait. Si tu regardes bien mon programmen, tu vas trouver la ligne :
AD1PCFGL= 0x03FF;
Cette ligne déclare (normalement, si je ne me trompe pas) les pins en numérique.
En revanche, je commence à avoir un gros doute sur le bon fonctionnement de mon PIC esclave. A force d'avoir souder/désouder, je me demande si celui-ci fonctionne encore bien. Je vais essayer avec un autre pic et je dirai ce qui se passe.

Cordialement

Crepuscule3

[RISC]

Bonjour,

Il est vrai que je n'avais encore pas vu ce registre de blocage. Cependant, les pins sont par défaut inscriptible, donc il ne devrait pas y avoir de soucis même sans jouer sur le registre OSCCON.

Je ne suis pas sur que tu aies compris mon post précédent : il est OBLIGATOIRE d'utiliser les sequences unlockIO et lockIO pour pouvoir programmer les broches RPxx du bloc PPS. Si tu ne le fais pas je te garantis que tes initialisations ne servent à rien. Relis encore une fois le paragraphe mentionné dans mon post précédent, ainsi que le paragraphe 9.4.4.1 de la datasheet des PIC24HJ12GP20x : http://ww1.microchip.com/downloads/e...Doc/70282B.pdf

Une petite astuce pour t'aider : utilise le configurateur graphique Visual Initializer de MPLAB pour programmer le PPS : Tools > Visual Initializer

En revanche, je commence à avoir un gros doute sur le bon fonctionnement de mon PIC esclave. A force d'avoir souder/désouder, je me demande si celui-ci fonctionne encore bien. Je vais essayer avec un autre pic et je dirai ce qui se passe.

Rassure-moi...tu utilises un débogueur (ICD2 ou Pickit2) ?
Sinon ca va être dur-dur de mettre au point ton logiciel.
Tu parles de souder-dessouder...tu utilises de la CMS ?
Et si non, pourquoi ne montes-tu pas des supports ?

a+

PS : les remarques ci-dessus s'appliquent au PIC24HJ12GP201 ET GP202

[invite8f8ffe44]

Bonjour,



Je ne suis pas sur que tu aies compris mon post précédent : il est OBLIGATOIRE d'utiliser les sequences unlockIO et lockIO pour pouvoir programmer les broches RPxx du bloc PPS. Si tu ne le fais pas je te garantis que tes initialisations ne servent à rien. Relis encore une fois le paragraphe mentionné dans mon post précédent, ainsi que le paragraphe 9.4.4.1 de la datasheet des PIC24HJ12GP20x : http://ww1.microchip.com/downloads/e...Doc/70282B.pdf

Une petite astuce pour t'aider : utilise le configurateur graphique Visual Initializer de MPLAB pour programmer le PPS : Tools > Visual Initializer



Rassure-moi...tu utilises un débogueur (ICD2 ou Pickit2) ?
Sinon ca va être dur-dur de mettre au point ton logiciel.
Tu parles de souder-dessouder...tu utilises de la CMS ?
Et si non, pourquoi ne montes-tu pas des supports ?

a+

PS : les remarques ci-dessus s'appliquent au PIC24HJ12GP201 ET GP202

Merci beaucoup pour ton aide!

Pour ce qui est de la communication SPI, j'ai testé mon hypothèse hier soir... en effet, mon pic avait dû chauffer un peu car je suis repassé sur ma plaque de test à trous et j'ai testé avec un autre pic 202 en dip cette fois... ça a marché du 1er coup!

Pour ce qui est du registre de blocage, il me semblait ben avoir compris qu'il fallait le faire de toute façon mais vu que ça marche maintenant, et sans l'utiliser, j'ai pensé que j'avais mal compris ce qui était marqué dans la datasheet.
Mais alors, ça changera quoi si je débloque les pins RPINR concernées? Je vais relire la datasheet pour être sûr.

Sinon, oui. J'utilise l'ICD2, et oui, mon pic 202 était en CMS. Pourquoi? Car j'avais envie de tenter de faire un circuit imprimé.

Merci encore pour ton aide précieuse.

Crepuscule3

[RISC]

Bonjour,

[QUOTE]
Pour ce qui est de la communication SPI, j'ai testé mon hypothèse hier soir... en effet, mon pic avait dû chauffer un peu car je suis repassé sur ma plaque de test à trous et j'ai testé avec un autre pic 202 en dip cette fois... ça a marché du 1er coup!
[\QUOTE]

Ca progresse ;=)

Pour ce qui est du registre de blocage, il me semblait ben avoir compris qu'il fallait le faire de toute façon mais vu que ça marche maintenant, et sans l'utiliser, j'ai pensé que j'avais mal compris ce qui était marqué dans la datasheet.
Mais alors, ça changera quoi si je débloque les pins RPINR concernées? Je vais relire la datasheet pour être sûr.

Je ne suis pas sur de ce que tu appelles le registre de blocage...J'imagine que tu parles de OSCON ?

Je ne comprends pas du tout...tu mentionnes que tu initialises et utilises le SPI SANS utiliser des séquences équivalentes à lockIO (avant initialisation des broches RPxx ) et lockIO (après initialisation des broches RPxx ) ci dessous ????

Ci-dessous les fonctions unlockIO() et lockIO() dont je me sers (équivalentes aux librairies) :

void unlockIO()
{
asm volatile ("mov #OSCCON,w1 \n"
				"mov #0x46, w2 \n"
				"mov #0x57, w3 \n"
				"mov.b w2,[w1] \n"
				"mov.b w3,[w1] \n"
				"bclr OSCCON, #6":::"w1","w2","w3");
}

//=================================

void lockIO(){

asm volatile ("mov #OSCCON,w1 \n"
				"mov #0x46, w2 \n"
				"mov #0x57, w3 \n"
				"mov.b w2,[w1] \n"
				"mov.b w3,[w1] \n"
				"bset OSCCON, #6":::"w1","w2","w3");
}

Sinon, oui. J'utilise l'ICD2, et oui, mon pic 202 était en CMS. Pourquoi? Car j'avais envie de tenter de faire un circuit imprimé.

Excuse ;=) J'ai cru que tu soudais/desoudais à chaque mise à jour...
Donc tu debogues et flashes avec l'ICD2.

N'oublie de prévoir sur ton CI un connecteur pour ton ICD2 : http://www.microchip.com/Microchip.W...edirects=icd2#

a+