 |
 |
| View previous topic :: View next topic |
| Author |
Message |
MattQ
Joined: 27 Mar 2011
Posts: 1
|
| PIC24H Serial Problems with Compiler Version 4.119 |
 Posted: Sun Mar 27, 2011 6:50 pm |
 |
|
Hello,
I have been using PCDIDE compiler with Pic24HJ128GP306 CCS development board for the past year or so and have many pains porting code over from a PIC18F6722 but today put me over the top and need help!! The majority of the issues have been related using printf and RS-232 communications and the chip not being able to process a printf statement with floating point data in a timely manner.
So for today's dilemma... when I updated my compiler from V4.116 to 4.119 and compiled the same code then executed it, neither of the PIC24H's UARTs or ISR involving the UARTs are operating.... No serial comms at all. All the timers and capture and compare ports are funitional.
I can't be the only one that has experienced this... and do not know where to go from here to debug this since it is so fundamental.
Has anyone else experienced this with 4.119 and what parameters were changed to get the UARTs working again....
Thanks in advance....
| Code: |
#include <24HJ128GP306.h>
#build(stack = 256)
#device ICD=TRUE
#include <math.h>
#include <string.h>
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include <SAS_STRUCT_101227.h>
#type FLOAT=32
#use delay (clock=20M)
#fuses HS,NOWDT, PR
#use rs232(STREAM=TELEMETRY, BAUD=115200, xmit=pin_F3, rcv=Pin_F2, PARITY=N, BITS=8, ERRORS)
#use rs232(STREAM=IMU_SERIAL, BAUD=115200, xmit=pin_F5, rcv=Pin_F4, PARITY=N, BITS=8, ERRORS)
|
|
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Mar 27, 2011 7:19 pm |
|
|
1. Make a very short test program that calls getc() and putc() in a while()
loop. Delete all the #include file lines except for the PIC's .h file. The
whole program should be 10 lines of code, maximum. You should only
have one #use rs232() statement in the program.
The main() portion of the code should look like this:
| Code: |
void main()
{
char c;
while(1)
{
c = getc();
putc(c);
}
} |
The other 4 lines will be, the #include for the PIC, the #fuses, the
#use delay(), and the #use rs232().
2. Then, compile it. Copy the .LST file to a temporary directory, maybe
c:\TEMP.
3. Then install the other compiler version. Re-compile.
4. Now, download and install the ExamDiff program. Run it and compare
the two .LST files for each version. If there are any significant
differences in the ASM code, you will see them highlighted by ExamDiff.
5. Also, you could test this program in hardware and see if it will echo
back to the PC, characters which you type into the terminal program
window (TeraTerm, etc.). Do this test for each compiler version.
Here is the download page for the free version of ExamDiff:
http://www.prestosoft.com/edp_examdiff.asp |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Mon Mar 28, 2011 1:27 am |
|
|
Personally, I have my PCD installation frozen to V4.112 due to some newly introduced arithmetic bugs, that CCS didn't yet manage to fix. So I had no opportunity to observe possible UART problems. They may be also device specific.
If you can provide a short example code, that reproduces the problem, I would be able to check the generated code and hopefully answer your question. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Mon Mar 28, 2011 1:59 pm |
|
|
I found that PCD V4.112 and V4.119 produce exactly identical code with your header for basic RS232 Rx and Tx.
So there must be something special only produced by your code. |
|
|
Matt Que
Joined: 16 Nov 2009
Posts: 14
|
|
| Posted: Wed Jun 27, 2012 9:03 pm |
|
|
Thanks for the replies all. Sorry for not replying as I have placed this project on hold for a bit but trying to get it figured out. My compiler version is up to 4.134 at this time and the problem is still there...
I have stripped down my code. I am connected to the PIC24H on a board using a Maxim 3222CWN+ RS-232 transceiver wired per the Maxim datasheet. The PIC PCB is then connected to a GUC232A usb-serial adapter in which I have realterm spewing out bytes of data repeatedly for debugging.
I have been able to isolate the problem down to the receive side of the configuration/system. At baud rates above 9600, the PIC is acting like it is inadvertently shifting bits and getting corrupted bytes transferred. I have been able to get good data transmitted from the PIC through the GUC232A into realterm at baud rates all the way up to 115200, but the PIC receives shifted bytes at any baud rate above 9600, 9600 and below are fine.
For example: @57600, I send 0x01 to the PIC, the PIC receives 0x03 confirmed by the ICD and spews back to RealTerm 0x03... everytime...
I am stuck here and not sure where to go... Any insight is greatly appreciated!
| Code: | #include <24HJ128GP306.h>
#build(stack = 256)
#device ICD=TRUE
//#device ADC=16
//#device ADC=10
#include <math.h>
#include <string.h>
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include <SAS_STRUCT_120624.h>
#type FLOAT=32
#fuses HS,NOWDT,PR
#use delay(clock=20000000)
#use rs232(BAUD=57600, UART2, PARITY=N, BITS=8, STOP=1, ERRORS)
void main()
{
while(TRUE)
{
T = getchar(); // Puts Input BYTE from AP_IN UART Port and copies it to a variable
putc(T);
}
} |
|
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Jun 28, 2012 11:53 pm |
|
|
I don't see a specific problem in the code. It's using the PIC24 hardware UART and utilizes the 4 character
hardware FIFO to transmit data up to the maximum rate.
As a guess about possible problems:
- An UART is by nature unable to synchronize to a continuous character stream. There must be a gap of more
than one character frame for unequivocal start synchronization. After that it should be able to follow the stream,
provided there are no overruns or hardware problems.
- If the stream is sent at maximum UART rate, it may be the case that your code can't keep up with with it on long
terms due to small crystal frequency or divider factor differences.
I presume that you didn't strip off essential code parts that change the picture. The definition of T is missing
presently, that must not mean a thing.
P.S.: I reviewed the PIC24HJXXXGPX06/X08/X10 errata sheet. It says in a short, that the UART doesn't work
correctly with BRGH=1, which explains the problem.
57600 operation is still possible possible with acceptable baud rate error and BRGH=0, for 115200, you need
a different crystal, e.g. 24 MHz.
In any case, you need to set BRGH and BRG manually for higher baud rates.
| Code: | #word U2BRG = 0x238
#bit U2BRGH = 0x230.3
U2BRGH = 0;
U2BRG = 10; // sets 56818 Baud, -1.4% |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Fri Jun 29, 2012 1:08 am |
|
|
If you have the IDE, you can also fix this directly from the device editor.
Select your device, and in the centre bottom of the screen, there is a box marked 'errata'. The top one is 'BRGH can not be 1'. Set it, and re-compile.
The compiler will then switch to get the best baud match it can using BRGH=0.
CCS normally set these when a chip has a particular problem. They didn't in this case, because the earlier engineering sample chips (A0), don't have this fault!....
Best Wishes |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Fri Jun 29, 2012 1:38 am |
|
|
Very good. I didn't yet come across this option.
P.S.: 24 MHz doesn't work for 115k baud rate, I forgot the factor two Fcy divider. |
|
|
Matt Que
Joined: 16 Nov 2009
Posts: 14
|
|
| Posted: Fri Jun 29, 2012 5:29 pm |
|
|
@FvM and Ttelmah,
Thank you so much for your help on this issue! I think I have been chasing this issue for quite some time. The PIC24H and the UART issues explained in the errata sheet appears to be a very likely cause.
I will give this a try tonight.
To answer your other comment;
| Quote: | I presume that you didn't strip off essential code parts that change the picture. The definition of T is missing
presently, that must not mean a thing. |
T was defined in one of those header files as a char. After a blast about not closely following directions from another person, I went and stripped out the rest of the libraries and redefined the variable and retested and had the same results.
Thanks guys for the help! |
|
|
Matt Que
Joined: 16 Nov 2009
Posts: 14
|
|
| Posted: Sun Jul 01, 2012 2:22 pm |
|
|
Guys,
That did the trick!
I do have the requirement to interface with devices that are communicating at 115200.
I am using a 20Mhz crystal. To get 115200 communication with BRGH=0, I enabled the PLL by configuring the clock to run at 40M.
| Code: | #include <24HJ128GP306.h>
#build(stack = 256)
#fuses HS,NOWDT,PR
#use delay(crystal=20M, clock=40M)
#use rs232(UART2, PARITY=N, BITS=8, STOP=1, ERRORS)
#word U2BRG = 0x238
#bit U2BRGH = 0x230.3
char T;
void main()
{
U2BRGH = 0;
U2BRG = 10; // sets 115200 Baud, -1.4%
while(TRUE)
{
T = getchar(); // Puts Input BYTE from AP_IN UART Port and copies it to a variable
putc(T);
}
} |
I am having difficulty understanding how this change will affect processor time while servicing the serial communication parts of the code....
Since the UART high speed modes with this family of pics are non operational at the higher baud rates, what are the considerations to the performance that I need to understand when using the PLL function. Is the system going to take more time servicing each transmitted and received serial byte than before by a factor of two? [Clock was at 20M, now at 40M, but BRGH = 1 to BRGH = 0 (Fosc/4 to Fosc/16)]
Or is this a completely transparent workaround in regards to timing and performance?
Thanks all! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Sun Jul 01, 2012 2:32 pm |
|
|
It won't affect code at all.
What it does is limits the range of baud rates that can be achieved with a given clock.
If you can use the IDE fix, the try selecting some higher rates, the compiler will start complaining at different rates than it does without the fix.
Best Wishes |
|
|
Matt Que
Joined: 16 Nov 2009
Posts: 14
|
|
| Posted: Sun Jul 01, 2012 3:12 pm |
|
|
AWESOME! Thanks!!
As a practical matter, should all the errata check boxes be selected in that window? Or are not all of those items list hardware specific and they are generally common errata across all PICs? |
|
|
|
|
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
