[PIC18] Problème de réception uart: Framing Error: FERR

[bonhommr]

Bonjour,

je cherche à coder une UART sur un PIC18F23K22.
pour la tester, je communique entre un hyperterminal et mon PIC.
La liaison fonctionne bien dans le sens PIC --> PC mais pas dans l'autre sens.

Lorsque je lis le caractère reçu, il n'est pas cohérent mais renvoie toujours la même chose.
Exemple, si j'envoie un 'a' (ASCII: 97), je reçois un 'O'(ASCII: 79).

En analysant, je remarque que le PIC remonte un erreur de Framing (bit FERR du registre RCSTA1).
D'après la doc, il semble que ce soit souvent dû à un problème d'horloge.
En mesurant à l'oscilloscope le même caractère émis par le PIC et le PC, il semble que les horloges soient ok.

Est-ce que vous avez une piste ou une idée pour m'aider à avancer ?

Merci d'avance,

registres.jpg
U_RX.jpgU_TX.jpg
-----

[RISC]

Salut,

Quel oscillateur utilises-tu ?
Peux-tu faire voir ton schéma ?
Bits de configuration ?

a+

[vincent66]

Bonsoir,
UNe erreur de plus de 1,5% d'horloge sera fatale pour une communication par uart, à l'oscillo tu n'y verras rien du tout..!
Vincent

[bonhommr]

J'utilise l’oscillateur interne à 16MHz

	// oscillator configuration
	OSCCON  = 0x70; // primary clock (CONFIG1H), 16 MHz internal oscillator
	OSCCON2 = 0x00;

// 16 bit baud rate generator (BRG16=1)
// Set baudrate to 9600bauds
	BAUDCON1 = 0b01101000;
	SPBRGH1 = 0x01;
	SPBRG1  = 0xA0;
	PMD0 |= 40; // Enable clock of UART1
// Enable Rx
// 8 bit reception
// Enable Serial Port
	RCSTA1 = 0b10010000;
// High speed rate (BRGH=1)
// Asynchronous mode
// Tx enabled
	TXSTA1 = 0b00100100;

Pour le schéma, je connecte le PIC sur un FT232RL qui sert à faire la conversion USB-UART.
Ce dernier est également utilisé avec un oscillateur interne.

Ce que j'ai du mal à comprendre avec les horloges, c'est pourquoi cela fonctionnerait quand même dans un sens.

Sinon, 1.5%, sur un temps bit de 100µs, ça fait une erreur de 1,5µs.
Sachant que j'utilise un scope très basique (Poscope Basic, sample rate 200kHz), c'est sûr que ce ne sera pas visible.
Je vais essayer de voir ça avec un scope un peu mieux.

Merci

[A voir en vidéo sur Futura]

[vincent66]

L'oscillo interne 16MHz est calibré à 1%, ce qui peut déjà poser problème... normalement pour un uart on utilise un quartz à 50 ppm...
Courage !
Vincent

[bonhommr]

Pour info, même à 300 bits par secondes, j'ai le même problème donc ça semble écarter le problème d'horloge.
J'ai utilisé trois configurations différentes pour OSCTUNE:
Standard -> temps bit mesuré: 3.332ms, Même problème
Valeur haute --> temps bit mesuré: 3.447ms, même problème
Valeur basse --> temps bit mesuré: 3.243ms, même problème

[jiherve]

Bonsoir,
Un UART basique pas trop mal conçu tolère presque 10% d'erreur de fréquence soit à peu prés un bit en mode 8 bits + parité.
Quel est le protocole physique : 232,422.
JR

[bonhommr]

Pour le protocole physique:
J'ai une liaison USB entre mon PC et la carte.
Sur la carte, j'ai un FT232R qui convertit l'USB en UART (et inversement).

Pour la config:
Baudrate: 9600
Data: 8 bits
Parity: None
Stop: 1 bit
Flow control: None

[mica25000]

Essaie un baud rate plus élevé, j'ai rencontré récemment ce problème avec un 18F46k22 avec oscillateur interne 16MHz, du coup j'ai suivi mon instinct et j'ai essayer plusieurs baud rates, et il s'avère qu'à 57600 baud ça tourne... essaie de voir aussi si desfois le FT232 n'y est pas pour quelque chose, si tu as possibilité de relier un MAX232 sur tes broches Rx et Tx essaie directement depuis le port série du PC, j'ai déjà eu des soucis avec ce genre de composants, étant donné la taille c'est pas toujours simple à souder sans le tuer... Microchip fait maintenant un équivalent en SOIC 20 (MCP2200 il me semble)

[RISC]

Salut,

Contrairement a ce qui est mentionné dans plusieur messages de cette pile, il FAUT ABSOLUMENT utiliser un quartz externe pour avoir une liaison stable.
Cela n'a RIEN à voir avec le choix de la vitesse. Les PICs sont généralement spécifiés à +/- 1% à 25C et cela dérive avec la température.
A part les dsPIC33 si ma mémoire est bonne qui sont spécifiés à +/- 2% sur toute la gamme de température et toute la gamme de tension, les autres PICs ont besoin d'un oscillateur externe.
Bien que la spec autorise +/- 2% (4% max entre les 2 noeuds), la plupart du temps les PC violent cette spec et nécessitent un noeud distant à +/- 1%.

Si tu as mis un quartz sur ton FTDI le PB ne devrait pas venir de là.

a+

[paulfjujo]

bonsoir,


Utilise tu le SOFTUART ou le HARD UART ?
mode pooling ou interruption ?
pour un seul caractere emis à la fois, dans les 2 cas l'UART est tranquille !
J'ai pas mal de montage UART qui fonctionne avec l'horloge interne sans probleme,
y compris un 18F46K22 à 8Mhz .
ou un petit 12F1840 à 8MHz ..

Avec une autre lettre que a ( qui donne O) , est-ce que les 2 quartets se retrouvent aussi inversés ?

Peux-tu mettre ton code en entier ?

[bonhommr]

Bonjour,

merci à tous pour vos réponse.
Je vais essayer de mettre mon code de façon lisible.
Dans le main.c, j'ai les bits de configuration suivants:

/// set configuration registers
// CONFIG1H
#pragma config FOSC = INTIO67  // FOSC = 0x8
#pragma config PLLCFG = OFF
#pragma config PRICLKEN = OFF
#pragma config FCMEN = OFF
#pragma config IESO = OFF
// CONFIG2L
#pragma config PWRTEN = OFF
#pragma config BOREN = SBORDIS
#pragma config BORV = 190
// CONFIG2H
#pragma config WDTEN = OFF
#pragma config WDTPS = 32768
// CONFIG3H
#pragma config CCP2MX = PORTC1
#pragma config PBADEN = ON
#pragma config CCP3MX = PORTB5
#pragma config HFOFST = ON
#pragma config T3CMX = PORTC0
#pragma config P2BMX = PORTB5
#pragma config MCLRE = EXTMCLR
// CONFIG4L
#pragma config STVREN = ON
#pragma config LVP = ON
#pragma config XINST = OFF
#pragma config DEBUG = OFF
// CONFIG5L
#pragma config CP0 = OFF
#pragma config CP1 = OFF
// CONFIG5H
#pragma config CPB = OFF
#pragma config CPD = OFF
// CONFIG6L
#pragma config WRT0 = OFF
#pragma config WRT1 = OFF
// CONFIG6H
#pragma config WRTC = OFF
#pragma config WRTB = OFF
#pragma config WRTD = OFF
// CONFIG7L
#pragma config EBTR0 = OFF
#pragma config EBTR1 = OFF
// CONFIG7H
#pragma config EBTRB = OFF
#endif

Ma gestion des interruptions se fait de la manière suivante:

void InterruptHandlerHigh(void);

#pragma code InterruptVectorHigh = 0x08
void InterruptVectorHigh (void)
{
  _asm
    goto InterruptHandlerHigh //jump to interrupt routine
  _endasm
}

#pragma code
#pragma interrupt InterruptHandlerHigh
void InterruptHandlerHigh(void)
{
	int_num++;

	if (PIR1bits.RC1IF == 1)
	{
		int_rx1();
	}
}

Ensuite mon main contient:

void main(void)
{
	
	// oscillator configuration
	OSCCON  = 0x70; // primary clock (CONFIG1H), 16 MHz internal oscillator
	OSCCON2 = 0x00;
	// configure PORTA
	TRISA  = 0b00000000; // 1: Input, 0: Output
	ANSELA = 0b00000000; // 1: Analog, 0: Digital
	LATA   = 0b11010000; // Set output level

	// configure PORTB
	TRISB  = 0b11110111;  
	ANSELB = 0b00000001;
	LATB   = 0b00001000;

	// configure PORTC
	TRISC  = 0b11110110;
	ANSELC = 0b00000000;
	LATC   = 0b00000000;

	//Configure interrupts
	PIE1 = 0b00100000;// enable interrupt on UART Rx
	
        uart1_init();

	// Activates global interrupt and interrupt on change on Port B (RB4 and RB5)
	INTCON |= 0xC8;
	INTCON2 = INTCON2 | 0b10000001; // disable pull-ups and high priority interrupt
	IOCB = 0b00110000;
    
	while(1)
	{

tx1('A');
Delay10KTCYx(250);
}
}

Pour le gestion de mon UART, j'utilise l'init suivante:

void uart1_init(void)
{
// UART setup
// No auto baud
// Wake-up disabled
// 16 bit baud rate generator (BRG16=1)
// Idle state on TX is low
// Received data are not inverted 
	BAUDCON1 = 0b01101000;
	SPBRGH1 = 0x01;
	SPBRG1  = 0xA0;
	PMD0 |= 40; // Enable clock of UART1
// Enable received
// 8 bit reception
// Enable Serial Port
	RCSTA1 = 0b10010000;
// High speed rate (BRGH=1)
// Asynchronous mode
// Transmit enabled
	TXSTA1 = 0b00100100;
}

La fonction tx:

void tx1(unsigned char c)
{
	TXREG1 = c;
	_asm NOP _endasm
	while(!PIR1bits.TX1IF);
}

Et la fonction rx:

void int_rx1(void)
{

	RCREG1=RCREG1;
}

Pour savori si ça pouvait venir d'une horloge, j'ai juste fait un rebouclage du Tx sur le Rx.
J'ai alors:
Caractère envoyé (hexa) Caractère reçu(hexa)
0x61 0x4F
0x00 0x00
0x01 0x7F
0x02 0x3F
0x04 0x1F
0xFF 0x00
0x10 0x20
0x40 0x01

Je pense avoir fait une erreur dans mon code mais je n'arrive pas à voir où.

Merci pour votre aide !

[RISC]

Salut,

Dans les bits de configuration il ne faut SURTOUT pas activer le bit LVP.
Dans ton interruption tu as apparemment oublié de remettre le flag d'interruption à 0 avant de ressortir de l'interruption...

a+

[paulfjujo]

bonsoir,


Pouquoi ne pas lire directement le caractere dans l'interrupt
d'ailleurs RCREG1=RCREG1; me parait anormal
reaffecter le contenu du registre dans le registre
j'aurais mis une variable .
la lecture du registre de reception devrait razer le flag d'interrupt.

autre soluce en utilisant la librairie C18
et un RAZ du flag , au cas ou ?

volatile char  c1;

void InterruptHandlerHigh(void)
{
	int_num++;

	if (PIR1bits.RC1IF == 1)
	{
		c1=Read1USART();
		PIR1bits.RC1IF=0;
	}
}

dans la partie Transmission, j'ai l'habitude de faire le contraire, verifier que le tampon est vide
avant d'envoyer le caractere

void tx1(unsigned char c)
{
	while(!PIR1bits.TX1IF);  // si le tampon n'est pas vide , on attend
	TXREG1 = c;
}

à suivre ...

[bonhommr]

Merci pour votre aide RISC et Paulfjujo.
J'ai modifié le code selon vos conseils mais ça ne résoud toujours pas mon problème.

Je pense exposer ce problème au support de Microchip à moins que vous ayez d'autres pistes.

De mon côté, je bloque un peu !!

[RISC]

Salut,

As-tu connecté un quartz externe ????
Pour réduire la source des problèmes (hard, soft) je te recommande très très fortement de connecter un quartz .

Tu trouveras un exemple de code pour l'UART dans les projets qui sont donnés avec la dernière carte PICDEM 2 PLUS car elle intègre un PIC18F46K22 qui est le grand frère du PIC que tu utilises

a+