Problème de transmission par UART sur PIC 18F

[netdefense]

Bonjour,

Je suis actuellement en stage de fin d'étude et je dois faire des test de consommation électrique sur 4 microcontroleurs de marque Freescale, Atmel, Texas et Microchip...

Je bosse actuellement sur le Microchip PIC 18F4620. J'essaie de mette en oeuvre le module UART (RS232). Donc j'ai programmer en premier lieu le registre TRISC avec '10111111' pour mettre le broche d'émission du RS232 en sortie et la broche de réception en entrée.

Ensuite je configure le registre TXSTA avec la valeur '00100010' (je veux mettre en place une liaison asynchrone low speed avec une transmission de donnée sur 8 bits)

Ensuite je configure le registre BAUDCON avec les valeurs suivantes '000000000'

Ensuite j'utilise la formule Baud rate = Fosc/(64(n+1))
j'obtiens donc n = 25 avec un Fosc = 4 MHz et un Baud rate de 2400
Je remplis donc le registre SPBRG avec '00011001' et le registre SPBRGH avec '00000000' (je me suis mis en mode 8 bits donc a priori ce registre n'est pas utilisé)

Une fois que j'ai fait ceci je passe a la réception. Alors en fait pour le premier test je relie les broche 2 et 3 du port DB-9 qu'il y a sur ma carte de test pour que le PIC soit l'émetteur et en même temps reçoive directement les données qu'il a lui même envoyée. Donc je règle le registre RCSTA avec la valeur '10010000'.

Donc pour moi ici la configuration est faite (j'ai activé la transmission sur le module USART et la réception en même temps) donc a partir de maintenant j'envoi les données (j'ai pris une valeur de 0x64). Je met donc cette valeur dans le registre TXREG.

Pour moi a partir de la je devrait recevoir la données dans le registre RCREG. Pour observer tout ça je me met en mode debug dans MPLAB.
Lorsque je rempli le registre d'envoi TXREG celui-ci prend bien la valeur 0x64. En même temps j'observe le TRMT du registre TXSTA et celui-ci passe bien a la valeur 0 car il est rempli. A l'instruction suivante le bit TMRT repasse bien a 1 ce qui indique a priori que le module USART a bien envoyé les données sauf qu'en même temps quand j'observe le registre de réception des données RCREG la je ne reçois rien du tout....

Voici mon code pour plus de clarté

#include <p18f4620.h>
#include <usart.h>

#pragma config OSC = XT, WDT = OFF,LVP = OFF

#define LED LATCbits.LATC5
#define sel_uart LATCbits.LATC4

unsigned long i;

void main(void)
{
	i=50000;
	//Activation du composant MAX232
	sel_uart=1;

	TRISC = 0b10111111;
	TXSTAbits = 0b00100010;
	BAUDCONbits = 0b00000000;
	
	SPBRGH = 0b00000000;
	SPBRG = 0b00011001;

	RCSTA = 0b10010000;

	while(!PIR1bits.TXIF);
		TXREG = 0x64;

	if(RCREG != 0x00)
	{
		//Allumage de la LED
		LED = 0;
		//Temporisation
		while(i != 0)
			i--;
		//LED Eteinte
		LED = 1;
	}
}

Donc voilà mon problème j'espère que j'ai été clair et que vous pourrez m'aider a résoudre ce problème que je n'arrive pas a résoudre après 2 jours de travail.

Merci d'avance
-----

[invitea5e3e6e1]

Bonjour
Pour mon lien RS232 j'utilise le mode interruption en reception caractère.

//------------------------------------------------------
// Reception un char sur interrupt et mise en memoire --
//------------------------------------------------------
#pragma interrupt ISR
void ISR(void)						// reception d'une interruption
{
	if(PIR1bits.RCIF)				// detection IT USART en reception
	{
		c=RCREG;
		*ptecr++ =c;
		if (ptecr >= &buffer[B_SIZE]) ptecr = buffer;
		PIR1bits.RCIF=0;
	}	
}
//--------------------------
// Vecteur d'interruption --
//--------------------------

#pragma code vecteurITH=0x18
void une_fonction(void)
{
	_asm goto ISR _endasm
}
#pragma code

void Put_char( unsigned char c)
{
	while(!TXSTAbits.TRMT);			// attendre registre libre
    TXREG=c;                		// envoie un caractère 
    while(!PIR1bits.TXIF);			// retour apres envoi
}

C'est avec un 18F458 et MCC18. Je suppose que c'est transportable à votre application.
Cordialement

[netdefense]

Bon je viens de faire un test avec l'oscillo et lorsque je rempli le registre TXREG avec une valeur, en observant la broche 25 (qui correspond à la ligne TX de la RS232) je ne vois strictement rien passer. Donc a priori l'envoi des données n'est pas effectuée...