Software uart works, not hardware uart-Solved

[dhenson]

Hi people. Thanks for the great forum.

I am going nuts trying to read a character from the hardware uart.

Code below, compiler version Version 4.039, 39089. Works fine on any arbitrary pin except the hardware uart pin. Ultimately, I would like to use the receive interrupt int_rda, but for now I'm just trying to read a silly keystroke.

I have tried different PCs running different terminal programs, different pics of the same type, different pics of different models, different max233 chips.

Any thoughts? Thanks!

[PCM programmer]

Check the connection between the Tx pin on the PC's DB9 connector
and the Max233. Also check the connection between the Max233 and
the PIC.

Post a list of the connections. Post the pin numbers that you are using
on each chip or connector.

[dhenson]

Thanks PCM.

Everything looks good with the connections from what I can tell. I even tried two different serial cables.

Also, these same connections work when I simply move the connection between the max233 and the pic to another pin on the pic.

I remain baffled.

By the way, using the command line version from MS Visual Studio. Could I be missing a command line option? Just thought of that. Hmmm...I ought to try it from mplab, but I don't have it installed. If anyone thinks it might help, I will install it.

example compile statement:

C:\Program Files\PICC\Ccsc.exe simpleIo.c /P2

Thanks.

[Ttelmah]

Try a simple test. Use:

#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS, FORCE_SW)

If it still doesn't work, you have ruled out the UART as the problem (since this will now be using the software serial routines).

Now, there is a big difference in what you may see on the hardware UART, versus the software UART, in certain circumstances. On the software UART, a 'getc', takes an entire character time. Getc, will start if the RX line is seen as 'low', at the moment the getc is called, or any time afterwards. With the hardware UART, the actual reception, will start at any time the line is seen as 'low', and _once the character has been received_, a 'getc', will return almost instantly. So, in the situation, that the line has noise on it, and is intermittently being seen as 'low', with your code, and the software UART, the LED will still be seen to flash (since any 'lows' in the time it takes to send the character will be missed, and the actual character reception will take long enough for the LED to be seen), but with the hardware UART, the LED won't be seen (since it'll only be on for a couple of uSec...).

Best Wishes

[RArtz]

I had the same issue with my hardware uart.
I think it has something to do with the initialization of the PIC, but not for certain. I did not look too much into it, because I didn't have a whole lot of time to get it working.

I do remember reading another post a few weeks ago that had a potential solution....but sorry I cant seem to find that post.

[dhenson]

Ttelmah: good idea. Same symptoms exactly when I use the force_sw switch. Did you really mean I rule IN the uart if this it worked? In any case, it didn't work, which makes me think it is something particular to the pin.

RArtz: Also a good idea. I found this:
setup_comparator(NC_NC_NC_NC);

which makes sense on the 16f88 part because it is shared with the comparator. The references seem to indicate this only applied to old compilers. Tried it and it didn't work. I am plowing through the datasheet on the 16f887 now to see what I can find there in the uart section...maybe there is something that needs to be initialized either for the uart or for pins C6 and C7.

Another symptom I noticed...the indicator led is staying high.

I have tried a different power supply setup to rule out power ripple, and have improved decoupling caps. No effect.

Thanks.

[dhenson]

Ttelmah: wasn't aware of the timing differences for the hardware and software getc(). I'll scope it out and try to make some sense of it. My hobbyist usb bitscope seems to be disturbing the signal quite a bit, so I'll have to work through that. Thanks.

[PCM programmer]

I don't have a 16F887, but I do have a 16F886, which is the 28-pin
version of the same PIC. I changed your indicator pin to Pin B2, so
it would work with the 16F886. I then installed compiler version 4.039
and tested it with the 16F886 on a PicDem2-Plus board. It worked.
It displayed your initial message, and I pressed the "asdf" keys over
and over again. This is with the hardware UART. Here's the output:

[dhenson]

Thanks PCM!

Your effort is greatly appreciated, and helps me know which direction to look.

I suppose it could also be a noise problem or other electrical problem like capacitance. I am currently working on a breadboard.

I will keep the board posted with everything I try and the results.

-Dave

[dhenson]

So in looking at the scope, my max 233 chip is receiving 20volts when I tap a key, but only giving me 1.8 volts out. I suspect this is just enough to drive a digital i/o pin in software, but not enough to drive the hardware uart.

Anyone know minimum specs on the pic uart, or the appropriate voltage level? I was expecting 5 volts.

Thanks.

[Ttelmah]

Since it failed on the same pin with software, you 'ruled out' the UART as the source of the problem.
I was ignoring voltage, since the other pin you selected, on paper has the same input levels as the UART pin. 1.8v, _would not be an acceptable 'high' for any pin (2.4v, is the lowest 'high' level required even by a TTL input buffer). I'd be looking carefully at the wiring round the 233. The output is specified to give 3.5v _minimum_, when running off a 5v rail.

Best Wishes

[dhenson]

Thanks Ttelmah.

Confirmed wiring on the max233.

I re-wired the thing with a max232 and recycled some 1uf caps from an old vcr I had sitting around. I am now getting 5V out with every keypress, and the hardware uart works like a charm.

What a pain.

I appreciate everyone's input.

-Dave

[Ttelmah]

At least you continued to go 'forwards' with the problem. Where it gets really bad, is when you go backwards faster than any progress that is being made....

Best Wishes