Searching \ for 'USART problems?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'USART problems?'.

Truncated match.
PICList Thread
'USART problems?'
1996\06\28@044616 by Scott Newell


I'm trying to get the usart on the 16c74 to talk to a pc, but I can't even
seem to get a stable signal out.  I'm seeing some *very* strange things
happening on the TX pin out of the pic, so I thought someone on the list
might be able to help out.

First, a few details about what I've got running.  It's a 16c74 running at
8Mhz driving a max233.  I've got 3 LEDs hooked up directly to the pic (who
needs current limiting resistors!); one to indicate a receive interrupt, one
to indicate that I've loaded the TXREG, and another that blinks about once a
second.  MCLR is tied high through a 100k resistor.   Enabled interrupts are
timer 0 (with maximum prescale), usart TX, and usart RX.  The usart is
config'd with BRGH low, SPBRG = 0x0c (~9600 baud, right?), 8 bits.  I'm
hooking the timer 0 interrupt to generate about 30 clock 'ticks' per second,
and I send a character out the port on each tick.  Well, actually I set a
flag bit then send the character out on the next usart TX interrupt.

I'm using portb as an input to select several test signals.  I can send a
continuous stream of '0000000', '11111111', '10101010', or '01010101'.  One
of the portd pins is pulsed high then low immediatly before loading the
txreg to trigger my scope.

What I observe is that the tx LED blinks rapidly, and over the course of
about 3 seconds, seems to ramp dimmer then snap back up to full brightness.
The LED blinking once per second also seems to lose brightness in about a 3
second ramp.  No evidence of this ramp on the supply rails, V+ is rock
solid, as is MCLR.

Now for the strange part.  When transmitting a constant stream of
'00000000', I can see the waveform fine for about the first 2 seconds or so
of the 'ramp-down', then it looks like the last bits (the msbs) are changing
from 0's to 1's. (Imagine going '00000000' -> '00000011' -> '00001111'
'00111111' as seen on the scope.)  This 'sweep' coincides with the minimum
brightness of the LEDs.  Then, as soon as all the bits seem to go high, the
whole damn cycle starts over again.  This is very obvious if I send the
output into a PC terminal program;  about every 4 lines of blanks is
interrupt by 10-20 random characters as the 1's sweep across.

Oscillator problems perhaps?  I'm running on a rat shack protoboard, so I've
got planty o' capacitance from anywhere to everywhere.  But the signal on
CLKOUT is rock solid on the scope and the clock period looks good.  The
length of the individual bits looks good, and stays constant as the LEDs
ramp down.

Power?  I tried a bypass on the MCLR pin, didn't make any difference.  As I
said, the rails are solid.  I've got 0.1uF on eache power pins, and 15uF of
tantalum across the rails.

Watchdog timer?  Right now it's enabled, and I'm clearing it constantly in
the main loop.

Timer 0 interrupt?  Could it conflict with the usart?

Reset circuit?  The errata claims the power-up timer may not work.  Maybe
the periphrials are not coming up completely?

It's getting early and I'm tired, so maybe the bug is dancing right in front
of me and I don't see it.  Does anyone else?

Any ideas from picland?  Please?

Thanks, (and sorry for the absence of brevity)


1996\06\28@054133 by fastfwd

Scott Newell <spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

{Quote hidden}


Sounds like two asynchronous signals beating against each other
(although the LED dimming, especially on the once-per-second LED,
mystifies me).  Since the only two asynchronous processes you're
running are the Timer-0 interrupt and the TX interrupt, try
lengthening your 1/30-second tick timer by a factor of 10 or 100 and
see if anything changes.

My guess is that your TMR0 interrupt-service routine is somehow
stomping on the TX registers or the TX interrupt flags.

Is there any chance that your code could be clearing the TXEN bit
during a transmission?


Andrew Warren -
Fast Forward Engineering, Vista, California

1996\06\28@110822 by Dana Frank Raymond

> I've got 3 LEDs hooked up directly to the pic (who
>needs current limiting resistors!); one to indicate a receive interrupt, one
>to indicate that I've loaded the TXREG, and another that blinks about once a
>second.  MCLR is tied high through a 100k resistor.

Steve, I havn't studied the details of your post in depth, but I did notice
two possible problems. First, what do you mean by LEDs hooked up 'directly'
to the PIC? No current limiting resistors? I don't know if you were joking
or not, but just because a port is rated at 25 mA maximum doesn't mean that
thats all it'll draw! Some method of current limiting is required. If the
part sources or sinks too much current it can become erratic for electrical
and thermal reasons (if the pin doesn't blow in the first place).

Secondly, a 100K pullup from MCLR to VCC is far too high. The databook
specifies 40K max. to prevent degradation of Vih due to leakage current
(+/-5uA). Could your data stream be going high due to false reset? Perhaps,
if the prescaler is assigned to the WDT, and its ON.

Regards, Dana Frank Raymond

1996\06\28@112324 by Martin J. Maney

On Fri, 28 Jun 1996, Scott Newell wrote:

> 8Mhz driving a max233.  I've got 3 LEDs hooked up directly to the pic (who
> needs current limiting resistors!); one to indicate a receive interrupt, one

It seems a bit unlikely, but why don't you add a modest offering to the
gods of specified absolute maximums by placing, oh, 100-220 ohms in
series with each LED?  With no ballast resistor each of those pins is
probably drawing two or three times the spec'd maximum - with three such
pins you could even be exceeding the supply-pin max spec, maybe.

I don't have any rational theory about how this is causing the symptoms,
but this stood out as the one thing in your description that sounded like
bad practice.

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...