| View previous topic :: View next topic |
| Author |
Message |
cerr
Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC
|
| rs232 issue |
 Posted: Wed Jun 15, 2011 2:25 pm |
 |
|
Hi There,
I'm using USART2 on my PIC18F86K22 to communicate with the PC @ 57600bps. Which works fairly well - sometimes - other times it isn't working (only after a power cycle). It seems like the USART might be hung or so..?
I'm using following definition:
| Code: | | #use rs232(baud=BAUDRATE,parity=N,xmit=PC_TX,rcv=PC_RX,UART2,bits=8,stream=PC, ERRORS) |
I thought I probably should check for rs232-errors just before my first printf() and in case of an error, I would disable and re-enable the uart with setup_uart() but how do I choose my USART2 to be controlled by setup_uart()?
Hints & suggestions are appreciated!
Thanks,
Ron |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Thu Jun 16, 2011 5:45 am |
|
|
food for thought..
Have you used the default UART with 100% sucess already? That would eliminate the PC side of the link as the problem.
Hate to see you waste time on 'it must be the PIC, when it's really the PC', not that I'd have ever done that ! |
|
|
cerr
Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC
|
|
| Posted: Thu Jun 16, 2011 9:47 am |
|
|
| temtronic wrote: | food for thought..
Have you used the default UART with 100% success already? That would eliminate the PC side of the link as the problem.
Hate to see you waste time on 'it must be the PIC, when it's really the PC', not that I'd have ever done that ! |
Uhm it seems like this kind of problem only started since I beefed up the baudrate. I At first to 115.2k then settled at 57.6k cause of the issues that started to appear, that said, 57.6k looks already better than 115.2 but it still isn't good enough and doesn't ALWAYS work which is a problem. Terminal wise, we've been experiencing problems of this kind on 3 different computers, two of them are using HyperTerm and I myself use TeraTerm and as said, we are all experiencing "the same" or similar behavior. Checking with my scope, I can't see terrible noise on the line on power up, only a very little "shake" which <shouldn't> cause issues. But it's gotta be something a like.... |
|
|
cerr
Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC
|
|
| Posted: Thu Jun 16, 2011 10:36 am |
|
|
I now added something like:
| Code: | if (RCSTA2&0x04 || RCSTA2&0x02) // if a framing error or an overrun error present
reset_cpu(); //start over |
before entering my main loop just to see what's happening but that doesn't seem to help either... :(
Something I've realized is:
- it isn't working for a while (meaning to data sent to the terminal)
- I un and replug it a few times
- all of a sudden weird characters appear as if the baudrate was set wrongly
- repower again and it will come up fine this time. Something I might should mention is, that I'm using a bootloader as well which might mess up things in the beginning? I'm using Microchip's AN1310 bootloader on my chip.
Any hints or suggestions?
Thank you! |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Thu Jun 16, 2011 8:49 pm |
|
|
You could see if running the baud rate 3% fast or slow makes things better or worse. Some PC baud rates are a little off, and of course the PIC internal clock is awful.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Fri Jun 17, 2011 8:47 am |
|
|
Yup, int_osc is NOT for accurate timing !!
Spend an extra buck and install a crystal and 2 caps ! Up here that hardware costs less than one minute of R&D programming time AND saves hours if not DAYZE of frustration trying to figure out why some program is 'hit and miss'.Rock stable hardware is the foundation to a quality product. |
|
|
cerr
Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC
|
|
| Posted: Fri Jun 17, 2011 9:38 am |
|
|
| I am running the PIC with a 20MHz crystal osc. |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Fri Jun 17, 2011 11:14 am |
|
|
Still try the +/- 3% to see if your PC may be a little off. I worked at a place that bought a whole bunch of NEC PCs that were a little slow in baud rate. Dropping our product baud rate 1% helped cut the error rate to these NECs without significantly affecting data to a "good" PC.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
cerr
Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC
|
|
| Posted: Fri Jun 17, 2011 1:38 pm |
|
|
| but even if I changed the baudrate by +/- 3% how come it's behaving differently if i'm running the application "on top" of a bootloader or just alone? |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Sat Jun 18, 2011 9:11 am |
|
|
| You don't show the actual ( physical) pins in your USE Rs232 . It's a long shot but you also have specified UART2 and it may be inconsistent with the pins you are using and if so the compiler may be generating a software uart instead. A software UART has more chance of having varying timing issues depending on the rest of the code ( bootloader no bootloader) than a hardware UART. |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Sat Jun 18, 2011 9:17 am |
|
|
| Quote: |
Code:
#use rs232(baud=BAUDRATE,parity=N,xmit=PC_TX,rcv=PC_RX,UART2,bits=8,stream=PC, ERRORS)
|
Could you pls post the full header of your code in order to know the whole settings of the MCU? |
|
|
cerr
Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC
|
|
| Posted: Mon Jun 20, 2011 9:44 am |
|
|
Hi,
Please see below:
| Code: | #include <18F86K22.h>
//#device ICD=TRUE
#case
#device adc=16 HIGH_INTS=TRUE
#fuses WDT1024,WDT_SW //Watch Dog Timer uses 1:65536 Postscale
#fuses HSH //Hi-Speed crystal oscillator
#fuses NOBROWNOUT //No brownout reset
#fuses NOPLLEN //No PLL enabled
#fuses BBSIZ1K //1K words Boot Block size
#fuses NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#fuses PROTECT
#fuses SOSC_DIG
#define MCU1_RX PIN_C7
#define MCU1_TX PIN_C6
#define PC_RX PIN_G2
#define PC_TX PIN_G1
#define BAUDRATE 57600
//#define PCBAUDRATE 59328
#use delay(clock=20000000)
#use rs232(baud=BAUDRATE,parity=N,xmit=MCU1_TX,rcv=MCU1_RX,UART1,stream=MCU1, ERRORS)
#use rs232(baud=BAUDRATE,parity=N,xmit=PC_TX,rcv=PC_RX,UART2,bits=8,stream=PC, ERRORS)
#use i2c(SLAVE, SDA=PIN_C4, SCL=PIN_C3, address=0x80, stream=i2c_LPR) |
|
|
|
cerr
Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC
|
|
| Posted: Mon Jun 20, 2011 10:35 am |
|
|
Before my first printf, I inserted following:
| Code: | if (RCSTA2&0x04 || RCSTA2&0x02) // if a framing error or an overrun error present
reset_cpu(); //start over
setup_uart(FALSE, PC);
delay_ms(500);
setup_uart(TRUE, PC);
set_uart_speed(BAUDRATE, PC);
fprintf (PC,"\r\n\r\nREG 1.5\r\n\r\n"); |
It doesn't really improve things and also I'm not sure how I tell setup_uart() and set_uart_speed() to use USART2. Is the stream identifier enough? Does it go back to the #use rs232 line to see that i actually want to re-initialize USART2?
Any other ideas would be appreciated!
Thank you!
Ron |
|
|
cerr
Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC
|
|
| Posted: Wed Jun 22, 2011 10:58 am |
|
|
Still fighting this issue, went down to a baudrate of 19200bps which is the absolute minimum for right now.
I I re-initialize UART 2 before I print anything else like this:
| Code: |
setup_uart(FALSE, PC);
setup_uart(TRUE, PC);
set_uart_speed(BAUDRATE, PC);
if (RCSTA2&0x04 || RCSTA2&0x02) // if a framing error or an overrun error present
reset_cpu(); //start over
|
But it doesn't seem to help of a whole lot... any clues what else the boot bootloader might be messing up?
Thanks,
Ron |
|
|
cerr
Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC
|
|
| Posted: Wed Jun 22, 2011 11:02 am |
|
|
| Douglas Kennedy wrote: | | You don't show the actual ( physical) pins in your USE Rs232 . It's a long shot but you also have specified UART2 and it may be inconsistent with the pins you are using and if so the compiler may be generating a software uart instead. A software UART has more chance of having varying timing issues depending on the rest of the code ( bootloader no bootloader) than a hardware UART. |
As for this, USART2 is using RG1 and RG2 on pins 6 & 7 which i implemented like this:
| Code: | #define PC_RX PIN_G2
#define PC_TX PIN_G1
#use rs232(baud=BAUDRATE,parity=N,xmit=PC_TX,rcv=PC_RX,UART2,bits=8,stream=PC, ERRORS) |
That sure should be using the hardware UART afaik. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
