problem UART pic18f6723

[alain-debutant]

hello everyone
my problem concerns RS232 with a pic18f6723
to send my 2 bytes I use the terminal "Hterm.exe"
i can correctly send and receive two bytes on port1 with int_RDA: example sending "BC" I light up my led, "BD" I turn off my led
on the other hand on port2 with int_RDA2 I send the same command I enter the RDA2 interrupt but it does not work, with the debugger my variable "pbuf" takes as value 1 (no more) and therefore my variable "buf" remains empty, while for port1 "pbuf2 " takes the value 2 and of course my variable "buf2" gives me "BC" or "BD"
i checked my pcb everything is OK
i despair ... can you help me please
thanks in advance for your help

code .C

/*
compilateur Picc compiler V5.118
programmateur : ICDU40 / ICDU80
*/

#include "main.h"

#ZERO_RAM

#INT_RDA2

void RDA2_isr(void)
{

buf[pbuf++] = fgetc(PORT2);

}



#INT_RDA

void RDA_isr(void)
{

buf2[pbuf2++] = fgetc(PORT1);

}


void main() {

output_low(led_t3);

pbuf = 0;
pbuf2 = 0;

enable_interrupts(INT_RDA);

enable_interrupts(INT_RDA2);
enable_interrupts(GLOBAL);



while(true) {
if(pbuf > 0) {
switch(buf[0]) {

case 'B':
if(pbuf == 2) { // Commande en 1 data ('B' + <data>)
switch(buf[1]) { // Switch prend une seule valeur (caractère ou nombre)
case 'C':
// ALLUMER LEDs
output_high(LED_t3);

pbuf = 0;
break;
case 'D':
// Eteindre LEDs
output_low(LED_t3);

pbuf = 0;
break;
default: // Autres cas
// Allumer 3e LED
// output_high(LED_TRANSPARENT);

break;
}
// pbuf = 0;
}
break;

}
}


if(pbuf2 > 0) {


switch(buf2[0]) {

case 'B':
output_high(led_t3);
if(pbuf2 == 2) { // Commande en 1 data ('B' + <data>)
switch(buf2[1]) { // Switch prend une seule valeur (caractère ou nombre)
case 'C':
// ALLUMER LEDs
output_high(LED_t3);

pbuf2 = 0;
break;
case 'D':
// Eteindre LEDs
output_low(LED_t3);

pbuf2 = 0;
break;
default: // Autres cas
// Allumer 3e LED
// output_high(LED_TRANSPARENT);

break;
}
// pbuf2 = 0;
}
break;

}
}


}
}

code .H
#include <18F6723.h>


#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)

#use delay(crystal=10000000)


#use rs232(baud=9600,parity=N,xmit=PIN_G1,rcv=PIN_G2,bits=8,ERRORS,stream=PORT2) // int RDA2
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,ERRORS,stream=PORT1) /// ecran int RDA


#DEFINE led_t3 PIN_B3

char buf[8]; // 5 : taille maximale buffer
int pbuf;
char buf2[8]; // 5 : taille maximale buffer
int pbuf2;

[temtronic]

hmm, you've got me confused....
Maybe I'm reading it wrong ??

data from the 2nd UART gets stored in the buf array while data from 1st UART gets stored in the buf2 array.

I'd like to see better naming, uart1 links to port1 links to buffer1.

[alain-debutant]

hello Temtronic
thanks for your interest in me, yes you read correctly, port1 = data buf2 in int_RDA
port 2 = data buf in in_RDA2
i simplified the code as much as possible in plain text to test I send the same thing to port1 and port 2
port 1 works correctly while port 2 does not take my bytes in the interrupt it enters it well but does nothing !!
i have already done this type of test in another pic like 26k22 and everything works I do not see where the problem is
thanks for your help, cordially

[alain-debutant]

I just did a test on another board with the SAME code with a pic 18f87k90 just by changing the #include <18F87k90.h> and the 2 ports work correctly, there must be a subtlety for this pic 18f6723 !!!! but I found nothing. I count on your knowledge ....
cordially

[Ttelmah]

Try setting up 'no_analogs' for the ADC port.

Your chip does not show analogs on these pins. However the 87K90 does.
By default the compiler will automatically turn off an analog peripheral
if present. Now given the 6723 does not show analogs on the pins this
won't be happening with this chip.

It is possible that the data sheet is in error and these pins do need the
analog turned off.

[alain-debutant]

Thank you Telmah for your response, I did what you recommended but it doesn't change anything. Could this be due to a problem with the defective pic?

[Ttelmah]

It was worth a try.
It could easily be a faulty chip, especially if it has not come from a legitimate
source. However I'll take the time tomorrow to see if the code being generated
for this UART is sensible.
Must admit I agree with Jay, you really should make the names reflect
what they are talking to. buff1 for UART1 etc. Not doing this increases the
chances of making a silly mistake somewhere.

[Ttelmah]

There is a very severe problem in how the code works.

If the UART does not return 'B' into that first character, and then
'C' or 'D', into the second location,
the buffer will carry on filling. After a few characters it will overflow, and
start overwriting values like the pbuf variable itself. Result disaster.

You have zero margin for any form of incorrect reception, and no recovery
if anything at all goes wrong.

Now it is very possible that the 6723, wakes it's crystal faster than your
alternative chip. If so, there may well be garbage received as a first
character. on the second port. It only takes the UART line to have not
gone completely high when the UART starts, and this will be the case.

Try something simpler and with trapping to prevent a buffer overflow
(in this case actually two traps):

[temtronic]

As a followup comment...
It'd be nice to have separate LEDs for status.
That way you know WHICH serial port has sent the commands.....

[alain-debutant]

Hello everyone
thank you Ttelmah for your answer and my updated code
i did the test and i still had the same problem. so i replaced the pic and with your code EVERYTHING is ok
thank you again for your help
good luck, cordially