CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

16F15344 serial port not waiting on key entry during getc()
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
robleso7473



Joined: 25 Mar 2009
Posts: 47

View user's profile Send private message

16F15344 serial port not waiting on key entry during getc()
PostPosted: Fri Jun 03, 2022 11:53 am     Reply with quote

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.

Code:

 do{
          printf(" ______________________________________________ \r\n");
          printf("|        Function Menu (Select Number):        | \r\n");
          printf("|----------------------------------------------| \r\n");
          printf("|1. Start PoE Detect State Machine             |\r\n");
          printf("|2. Read PoE Status                            |\r\n");
          printf("|3. Read PoE Current (mA)                      |\r\n");
          printf("|4. Read PoE Voltage (V)                       |\r\n");
          printf("|5. Enter 24V Current Window Limits (mA)       |\r\n");
          printf("|6. Enter 48V Current Window Limits (mA)       |\r\n");
          printf("|7. Read 24V Current Window Limits (mA)        |\r\n");         
          printf("|8. Read 48V Current Window Limits (mA)        |\r\n");
          printf("|9. Revision History                           |\r\n");
          printf("|a. Enable Canopy PoE Polarity                 |\r\n");
          printf("|b. Enable Standard PoE Polarity               |\r\n");
          printf("|______________________________________________|\r\n\r\n");
          restart_wdt();
          printf("Enter Selection>");
          selection = getc();
          putc (selection);
      }
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Jun 03, 2022 1:19 pm     Reply with quote

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



Joined: 25 Mar 2009
Posts: 47

View user's profile Send private message

PostPosted: Fri Jun 03, 2022 2:47 pm     Reply with quote

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



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Jun 03, 2022 3:09 pm     Reply with quote

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



Joined: 25 Mar 2009
Posts: 47

View user's profile Send private message

PostPosted: Fri Jun 03, 2022 3:22 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jun 04, 2022 4:59 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sat Jun 04, 2022 11:18 pm     Reply with quote

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... Sad
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Jun 05, 2022 6:01 am     Reply with quote

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



Joined: 25 Mar 2009
Posts: 47

View user's profile Send private message

PostPosted: Mon Jun 06, 2022 7:12 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Jun 06, 2022 7:47 am     Reply with quote

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



Joined: 25 Mar 2009
Posts: 47

View user's profile Send private message

PostPosted: Mon Jun 06, 2022 7:48 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Jun 06, 2022 10:16 am     Reply with quote

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



Joined: 25 Mar 2009
Posts: 47

View user's profile Send private message

PostPosted: Mon Jun 06, 2022 10:30 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Jun 06, 2022 1:47 pm     Reply with quote

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



Joined: 25 Mar 2009
Posts: 47

View user's profile Send private message

PostPosted: Mon Jun 06, 2022 1:58 pm     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group