Baud rate Issues for UART2 on PIC18F65J11

[mayur.k.vadukul]

I have been using UART1 & UART2 with PIC18F66K22 device and I have been doing the following to get the right baud rates for our systems:-

#use rs232(UART2, baud=9600, ERRORS, STREAM = FM_UART) //Set 2nd UART to 9600 Baudrate
#use rs232(UART1, baud=4322, ERRORS, ENABLE=DATA_DIR, DISABLE_INTS, STREAM = BUS_DATA) //For Data Bus

The code was running as expected and there were no issues.

I then changed the microprocessor from PIC18F66K22 to PIC18F65J11 (Pin Compatible) , and I have changed the device on my board keeping the code exactly the same as above. The code compiles too, but for some reason the baud rate for UART2 is unexpected. I don’t understand what could be the difference.
_________________
MVadukul

[temtronic]

I don't use those PICs but....
It could be a compiler 'bug'
Post your version and someone with it can confirm/deny the 'bug' .
You should dump the listing to see what bits are being configured in the 'baud rate' register.

[Ttelmah]

What do you mean 'unexpected'?. Slow, fast, etc. etc..
What is the master oscillator frequency in both cases?.
Post the actual #PIN_SELECT lines for the UART.
What compiler version?.

[mayur.k.vadukul]

@ temtronic, see the listing below:-
.................... #use rs232(UART2,baud=9600,ERRORS, STREAM = FM_UART) //Set 2nd UART to 9600 Baudrate
*
0B6E: BTFSS FA4.4
0B70: BRA 0B6E
0B72: MOVWF F62
0B74: RETURN 0
@temtronic,
It is faster than 9600. the bit rate for working 9600 is 104uSec and non working code is 32uSec.
I don't understand what do you mean by #PIN_SELECT lines?
The compiler version is 5.109.
_________________
MVadukul

[Ttelmah]

Both of your chips are not PPS chips. Very surprising for a J chip.
However you haven't answered the oscillator question?.

[mayur.k.vadukul]

On both occasion the crystal is 16MHz and it is run at 64MHz using PLL.
#use delay(clock=64MHz,crystal=16MHz,restart_wdt)
_________________
MVadukul

[Ttelmah]

Also the baud rate setting code is not at the #USE line, but at the start
of main. Look there.

The J11, is not rated to run at 64MHz. 40MHz max. Probably why it is
not working right....

[mayur.k.vadukul]

I am sorry but I do not understand your comments.
_________________
MVadukul

[mayur.k.vadukul]

I have also tried disabling the PLL and ran the system at 16MHz crystal and it still did not work.
On scope, i tried delay function, checked timer interrupt and UART1. It all worked fine but the UART2 doesn't want to know. I happened to have the code in XC8 compiler as well and it is working fine. So there got to be the bug in the compiler. Do you know any other method to set the baud rate?
_________________
MVadukul

[Ttelmah]

OK.

The point I was making, was you posted the stuff generated by the
#use as if this could affect your UART. However this is just the transmit
and receive code (just the start of it posted). The UART _setup_ does
not appear here, but at the start of the main in the listing. So:

[mayur.k.vadukul]

Thanks for the in depth insight into the issue.

I have tried running the device with 16MHz as well. However, that did not work too. More so, I have use delay_ms (), function and check on the scope whether it produces right results to ensure that the clock is how i have set up. My UART1 works well as I have checked on the scope and so does my timers routine. (checked on scope too). All of these have been tried using both 16MHz & 64MHz. I understand the chip defines it to run with 40MHz max but not sure whether that is the highest frequency of the physical crystal or the actual clock after PLL. Anyway, for the purposes of the testing I have disabled PLL and ran purely as 16MHz as stated above and it still did not work.

I will try adding assembly code to get around and see what happens.

However, when I contacted CCS support, they sent me new pch.dll file as they admitted there is bug in the compiler for the microprocessor I am using. Now, when I pasted, in hurry i forgot to back up the original file and as a result now my CCS compiler program does not run due to CRG mismatch. :(
As soon as I get any response from the CCS, I will keep you posted of the findings and will be interesting to implement assembly lines too.

Many thanks and fingers crossed.
_________________
MVadukul

[Ttelmah]

From CCS to me:

[Ttelmah]

On overclocking, there is a lot to this.
First individual instructions and peripherals may simply not work.
Then the chip will run hot.
Then it may well stop operating at temperatures well below it's rated limits.
Long term this can destroy the chip.
As I said, in fact what your chip was doing was the PLL was failing to work
at this rate. It was not able to clock at the 64MHz rate, and was locking to
32MHz.
Small overclock levels (perhaps 10%), will almost certainly work fine.
Levels over perhaps 20% are likely to have/cause problems.

[temtronic]

OK, I'm real curious...
What device has a baudrate of 4432 ??