 |
 |
| View previous topic :: View next topic |
| Author |
Message |
mad_zero
Joined: 27 May 2015
Posts: 4
|
| PIC24F 8M internal oscillator and UART speed problem |
 Posted: Wed May 27, 2015 6:38 am |
 |
|
PCWDH 5.045
UART communication speed problems.
PIC24F16KA102 communicating with XBee module over UART.
8MHz internal clock.
It only operates reasonably well at 115200 but still have high error percentage. When I try to communicate at 9600 or any other baud rate data delivery failure rate increases significantly, to approx 99% being lost.
Obviously when I change PIC baud rate I do the same and on the XBee module over XCTU.
When I try manually preset baud rate, it makes no effect at all.
| Code: | #word U2BRG = 0x0238
#bit U2BRGH = 0230.3
...
void main() {
U2BRGH = 0;
U2BRG = 25; //9600
...
}
|
It doesn't even operate at 1200 baud rate.
| Code: |
#include <24F16KA102.h>
...
#FUSES CKSFSM
#FUSES NOBROWNOUT
#FUSES FRC
#FUSES MCLR
...
#use delay(clock=8290000) // baud rate out of range trick
#use rs232(baud=112500, UART2, stream=XBEE, xmit=PIN_B0, rcv=PIN_B1, bits=8, errors)
...
|
|
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9229
Location: Greensville,Ontario
|
|
| Posted: Wed May 27, 2015 7:05 am |
|
|
Try using a real xtal and 2 caps as the 'clock' source.
The internal oscillator ain't great though I'd expect it to be better.
Using a real xtal, even for test purposes will shed more light on the real problem.
Jay |
|
|
mad_zero
Joined: 27 May 2015
Posts: 4
|
|
| Posted: Wed May 27, 2015 7:12 am |
|
|
| temtronic wrote: | try using a real xtal and 2 caps as the 'clock' source.
The internal oscillator ain't great though I'd expect it to be better.
Using a real xtal ,even for test purposes will shed more light on the real problem.
Jay |
That's the problem. I have 50 boards manufactured and have to make it work as it is =] I don't mind low speed.
I just can't see the reason why this can't work at 1200 baud rate. =( |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Wed May 27, 2015 7:25 am |
|
|
Add BRGH1OK to the RS232 declaration.
This should really always be present _on any chip which does not have the BRGH problem_, when trying to synthesise high rates.
Without this, on your chip at 8MHz, the nearest you can get to 115200, is with BRG=1, which will give 125000bps. No wonder the compiler warns!...
With BRGH1OK, it'll instead use BRG=8, and BRGH=1, which will give 111111Hz, which is still about 3.5% in error.
8MHz, really is too slow to synthesise this rate 'well'. The BRG, uses Fosc/8, or Fosc/32, so master clocks of 1MHz, and 250KHz only. As currently setup, it is using the 250KHz clock, but even using the 1MHz clock, still results in significant error. Put your clock figure to 8MHz. You are currently telling the compiler to accept even more inaccurate times, and for the low rates actually synthesise times that are badly in error...
The figure you are using trying to program it yourself is massively 'wrong'. No wonder it doesn't work. Check your calculations...
However the compiler will get the calculation right, if you let it do it's job, with 8MHz as the clock rate.
A proper crystal will help enormously, especially if you use one that is a multiplier of the required rate. A crystal like 8.2944MHz
You'd also get a much closer rate if you use a faster clock. 16Mhz, is available to you using the PLL, and the error at 115200, with this and BRGH, drops significantly.
Also have you done a basic test and verified your chip is actually running at 8Mhz?. |
|
|
mad_zero
Joined: 27 May 2015
Posts: 4
|
|
| Posted: Wed May 27, 2015 8:23 am |
|
|
| Ttelmah wrote: | Add BRGH1OK to the RS232 declaration.
This should really always be present _on any chip which does not have the BRGH problem_, when trying to synthesise high rates.
Without this, on your chip at 8MHz, the nearest you can get to 115200, is with BRG=1, which will give 125000bps. No wonder the compiler warns!...
With BRGH1OK, it'll instead use BRG=8, and BRGH=1, which will give 111111Hz, which is still about 3.5% in error.
8MHz, really is too slow to synthesise this rate 'well'. The BRG, uses Fosc/8, or Fosc/32, so master clocks of 1MHz, and 250KHz only. As currently setup, it is using the 250KHz clock, but even using the 1MHz clock, still results in significant error. Put your clock figure to 8MHz. You are currently telling the compiler to accept even more inaccurate times, and for the low rates actually synthesise times that are badly in error...
The figure you are using trying to program it yourself is massively 'wrong'. No wonder it doesn't work. Check your calculations...
However the compiler will get the calculation right, if you let it do it's job, with 8MHz as the clock rate.
A proper crystal will help enormously, especially if you use one that is a multiplier of the required rate. A crystal like 8.2944MHz
You'd also get a much closer rate if you use a faster clock. 16Mhz, is available to you using the PLL, and the error at 115200, with this and BRGH, drops significantly.
Also have you done a basic test and verified your chip is actually running at 8Mhz?. |
Unfortunately I can't use crystal as boards are already manufactured.
Yes, I tried BRGH1OK and BRG=8, and BRGH=1 and tried all rates from 1200 to 115200 with set_uart_speed. Only 115200 works, but works with loses.
Updating PCWDH didn't help. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Wed May 27, 2015 8:55 am |
|
|
I repeat my question:
"Also have you done a basic test and verified your chip is actually running at 8Mhz?."
The lower rates should be _more_ accurate than the high one. With BRGH1OK added the compiler will allow 115200, if you go to 16Mhz (seriously, it is _right_ the error is too large at 8MHz/115200).
Using:
| Code: |
#include <24F16KA102.h>
#FUSES NOWDT
#FUSES NOCKSFSM //Clock Switching is disabled - I want to _know_ if the clock is not working
#FUSES NOBROWNOUT
#FUSES NOMCLR
#device ICSP=1
#use delay(internal=16000000)
#use rs232(UART1, baud=38400, errors, brgh1ok, stream=UART_PORT1)
void main()
{
while(TRUE)
{
fputc(0xAA,UART_PORT1);
fputc(0x55,UART_PORT1);
}
}
|
The chip merrily outputs bytes at 38573bps (error less than 0.4%). Switching to 9600baud, it gives 9616.5bps (less than 0.2% error). So my example has a nice accurate clock and is behaving as it should. At 115200, it gives just under 117700bps. All exactly as they should be.
Have you considered there might be something wrong with your circuit to convert to RS232 levels (assuming you are using one), and that in fact it is failing to maintain the voltage levels at low baud rates?. You may well be chasing a 'hare', and actually have another problem.
Not allowing 115200, at 8MHz, is the 'right' decision from the compiler, though you can make it work, you are 'straining' the accuracy requirements. |
|
|
mad_zero
Joined: 27 May 2015
Posts: 4
|
|
| Posted: Thu May 28, 2015 5:08 am |
|
|
| OK, I found the problem. It was in received data handler function. Thanks Ttelmah for telling me to look for a problem somewhere else, not in UART setup. =] |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Thu May 28, 2015 6:26 am |
|
|
| mad_zero wrote: | | OK, I found the problem. It was in received data handler function. Thanks Ttelmah for telling me to look for a problem somewhere else, not in UART setup. =] |
You titled this thread, "PIC24F 8M internal oscillator and UART speed problem" Clearly that 's where we focused our attention - on the things you highlighted, as presumably that's where you though the issues was. Not on some other code that until the last minute you had not even told us existed!
Personally, I was wondering how you were measuring these failure rates... As you were receiving sensible advise, especially about possibilities to eliminate, I felt no need to add my thoughts. So, were you in fact getting good comms, but then misinterpreting the data, or what? What, in fact, was the problem? |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
