HSEROUT problem at 20MHz

I am using a PIC18F452, with a MAX232 and the HSEROUT function to communicate with my PC over a 3m long serial cable. My code is based on the famous post on this forum (many thanks!):

DEFINE OSC 4

TRISC = %10000000 'PORTC.7 is RX input PORTC.6 is TX output. Using internal USART and MAX232 to interface to PC

DEFINE HSER_RCSTA 90h 'Enable serial port. Enable continuous receive

define HSER_TXSTA 24h 'Enable transmit. BRGH=1

define HSER_SPBRG 12 '103 for baudrate of 2400 @ 4MHz (25 for 9600 @ 4MHz; 12 for 19200 @ 4MHz)
DEFINE HSER_CLOERR 1 'Automatic clear overrun error

'Alias definitions
RCIF VAR PIR1.5 'Receive interrupt flag (1=full , 0=empty)
TXIF VAR PIR1.4 'Transmit interrupt flag (1=empty, 0=full)

SerialData var byte 'Variable definition

pause 100 'Start-up delay
Main:
if RCIF then 'Incoming data?
hserin [Serialdata] 'Take it
hserout [serialdata] 'Send it
endif
goto main


This provides perfect 2-way comunications at 4MHz with any of the following settings:

'TXTA 24h with SPBRG 103 (gives 2400 baud)
'TXTA 24h with SPBRG 25 (gives 9600 baud)
'TXTA 24h with SPBRG 12 (gives 19200 baud)

.... but when I change the clock to 20MHz and alter the SPBRG value according to the datasheet, there is no comms at all. For example, although 19200 baud requires SPBRG to be 64, this produces nothing.

I'm desperate! Any ideas folks?

You changed the "define OSC 4" to "define OSC 20" too ?

AND you set the HS config fuse in your code or before programming in your device programmer software?

Hellow guys,

Yes, I changed the programmer clock speed config. setting to HS and the DEFINE OSC 4 to DEFINE OSC 20

Sometimes, the breadboard could cause you some bugs like that. But before doing some assumption, is a simple Blink program work? Some crystal also need a resistor in parallel to work properly.. something 'round 1Meg

If not, remove the capacitor around your Crystal, ALSO be sure your supply line is clean, ... plah plah, capacitor close to PIC and the usual.

DOH! i already saw that code here ... i guess it's one of mine.. there's a little error in the DEFINE HSER_CLOERR... MUST BE DEFINE HSER_CLROERR

Do a simple loop with HSEROUT and post your results.

Thanks for your suggestions. I corrected the CLROERR microbug, with no effect and then inserted an [LED ON : PAUSE : LED OFF] bit between the byte receive and byte echo lines in the code. This proved that the micro and code were running, with the LED blinking for each byte received. However, after a random number of bytes received (typically 6), the program stops with the LED on.

Tidying up the breadboad wiring and moving the power input lines connection to the board greadtly improves things. Most of the bytes are now echoed correctly, with a few random errors. This all suggests that it is a board layout problem giving noise on the power lines that latches up the micro. The funny thing is that I used 9600 baud with 20MHz, no absolutely problem, when using SEROUT and NO MAX232. It seems that the MAX232 is producing these glitches.

I hope the problem will be fully solved when I go to a PCB. Thanks for the suggestions.

Yet another poor psu filtering issue now. Place 1uf-10uF tantalum + 0.1 ceramic close to the MAX232, same close to your PIC and it should work better.

Sure a PCB may be of help but solving this problem on a breadboard will learn you some important things. It's working smooth here on a breadboard and the same OSC speed you use.

Keep your OSCillator wires/pins short, same for capacitors around your crystal. Ceramic Resonator are my favorite choice when using a breadboard.. not for a final PCB if accuracy is important with temperature change.
Don't do any Spaghetti breadboard... all wires will act as an antenna and just introduce noise. If your breadboard have a metal plate on the bottom, ground it... it will act as a 'kind of' ground plane. Messy contact, wich is often the case on breadboard after few hours of use, will also give you headaches. order a load of 0.1 uF ceramic capacitor + 10uF tantalum and sprinkle them 'round your breadboard supply line... you'll be surprise of how it solve some problem.

Some ICSP problem are also often a case of bad breadboard assignement, were wires are too long, psu poorely filtered and, and,and...

Problem has been completely solved, as you suggested, by putting 0.1uF ceramic caps spanning the power supply lines to the PIC and the MAX232 on my breadboard. Thanks for the solution.

Incidentally, I found another problem relating to power supplies when experimenting with the 16F877. Like many PICs, the device has 2 pins (on opposite sides of the DIP) for each of the VDD and VSS connections. Thinking it would be good to connect up both sets, I found the PIC drew a heavy current and did'nt work. Only one pair should be used. The datasheet does not detail this.

__________________________________________________ ___________
In electronics there is no such thing as a new idea, only new applications of old ideas.

Quote:

---

Originally Posted by manxman

Incidentally, I found another problem relating to power supplies when experimenting with the 16F877. Like many PICs, the device has 2 pins (on opposite sides of the DIP) for each of the VDD and VSS connections. Thinking it would be good to connect up both sets, I found the PIC drew a heavy current and did'nt work. Only one pair should be used. The datasheet does not detail this.

---

Many of the larger PICs have multiple power pins.

ALL OF THESE SHOULD BE CONNECTED.

They are not duplicated to make PCB layout easier, they are there to feed power to all parts of the chip without burning out internal tracks. IF you only use one set you will eventually damage a PIC and could also have eratic behaviour of your program.

I would respectfully suggest that the reason your PIC drew a heavy current and didnt work was due to inadvetantly shorting out the power supply as the two sets of pins are NOT exactly opposite but slightly offset making a wiring error a distinct possibility particularly when breadboarding a design.