16F15344 serial port not waiting on key entry during getc()

[robleso7473]

Hi All,

I am running a basic serial menu that prompts user to enter one of 11 keys.
However, as soon as the getc() function is called, it does not wait for key entry, it just jumps ahead to next instruction. This exact same code worked on the PIC16F15386 sister part which I used before.

Does anyone know if the 15344 has an issue with the getc() function?

See code below.

[PCM programmer]

The errata sheet doesn't list any problems with the UART.

Turn off Watchdog timer and see if you still get the problem.

If that doesn't help then tell us what circuits or chips are driving the Rx pin.
And tell us if you have the proper bypass caps on the PIC's Vdd pins, etc.
And your compiler version.

[robleso7473]

I used #fuses NOWDT to disable WDT and had no effect.

I'm driving an FTDI TTL-232R-5V cable. I am powering the 15344 at 5.2V.
I'm trying to attach a snippet of my schematic but can't figure out how to attach it. I don't have a http: url link to my image.

Compiler version 5.109

I ran an experiment by removing the RX input from the FTDI yet the TX continued to cycle my menu printf statements over and over bypassing the getc() function. So there's no RX input issue causing this as far as I can tell.

[PCM programmer]

Post your #use rs232() statement


To post an image, you upload it to a free image hosting service such as:
https://imgbb.com/
Then get the hotlink for it (it will say the link for a forum), and post that here.

[robleso7473]

I figured it out PCM Programmer.

#use rs232(baud=9600,parity=N,xmit=PIN_B7,rcv=PIN_B5,bits=8,stream=PORT1,restart_wdt,disable_ints,errors)

In the #use rs232 statement, which I copied from my F15386 design I forgot to change the rcv pin to PIN_B5. I had it set to PIN_C6.

I apologize for wasting your time on this.

thanks,
Oscar

[temtronic]

oopsy ! That silly stuff comes from either the coffee pot being empty or having had 3 in a day.....
We've ALL 'been there,done that'.....
Welcome to the 'club' !!

[Ttelmah]

and this is also why we so often push to check things that posters
'know' are not the problem!. It is amazing how often it is something
totally basic like this that is the real problem...

[temtronic]

sigh, it took me YEARS to get used to the new 'RS-232' connectors when 9 pins become the 'standard. WHY did 'they' flip the use of 2 and 3 ? arrrrgh.

[robleso7473]

I really am sorry, I did spend quite a bit of time troubleshooting this on my own before I decided to submit this question on the forum. Even on that same #use rs232 statement I tweaked a few parameters but totally missed the rcv pin being incorrectly set.

I appreciate the prompt support your team has provided.

One other related question that I have on the rs232 function, on this F15344 device when I set baud=115200 my serial port does not see correct characters. Is there a different number I should use to enable 115.2kbps comms? I thought I saw somewhere that it needed to be higher, like 125k or 130k.

thanks,
Oscar

[Ttelmah]

No.
What is your CPU clock rate?. This determines the accuracy of the baud
generation. However the compiler will normally warn is the calculated
value differs by more than a couple of percent from what is being requested.

[robleso7473]

I'm running it at full 32MHz (internal). I don't recall seeing a warning on baud rate when I compiled.

[Ttelmah]

Problem is that RS232 will usually start to go wrong if the baud rates at
each end differ by more than perhaps 2.5%. The compiler warns if the
divisions it can use will give more than a couple of percent error, but
remember that the internal oscillator is already quite inaccurate.
+/-2%. Now I'd suspect it'll be selecting a divisor of 69, which will
give a slightly fast baud rate (by about 0.6%). It only tales your internal
oscillator to be running perhaps 2% fast for the baud rate to then be
unacceptable.
Try specifying the baud as 114300. This will force the next divisor up
to be used. If it then works you know your internal oscillator is fast.
Beware though that if you then change to another chip that has a slow
oscillator, you may go out of tolerance the other way.....
I'm suggesting going this way based on which way the likely error is.

[robleso7473]

I tried the lower baud rate of 114300 but it had no effect.
I dropped it down to 110000 in 1k intervals and it got worse.
I then changed direction and started increasing baud rate from 115500 by 1k until at about 120500 it spit out the correct characters. It appears the oscillator is quite slow instead of too fast.

What's the general recommendation for using this rs232 function? To use a more accurate external oscillator?

thanks,
Oscar

[temtronic]

For accurate, repeatable, near bullet proof performance, you should use a crystal/2 caps, if possible one that has a 'binary' for exact speed for the UART.
Microchip should have 'suggested' xtal vs baudrate charts in the datasheet.

Also be aware that TEMPERATURE can affect the baudrate generator ! Another reason to use the xtal/2 caps.

[robleso7473]

Yes, if I were to have a serial console available on this product I would load the XTAL but just need it for development/troubleshooting at this point. I'll try not to put this board out in the hot Arizona sun :D

thanks a million for the support.
Oscar