 |
 |
| View previous topic :: View next topic |
| Author |
Message |
cbarberis
Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA
|
| Weird issues with PIC24H |
 Posted: Thu Apr 23, 2009 8:08 pm |
 |
|
I wonder if anyone has suffered with the PCD compiler like I have in the last few days. I thought I give CCS another chance by using the PCD compiler, in the past, I have tried it and found it so buggy, that I just gave up and purchased the C30 compiler from Microchip, I have done a few new projects on the C30 and all have worked albeit, it was a very steep learning curve. Because I have been using CCS for all the 8bit controllers and grown familiar with it, I want to see if I can use it on the 16bit devices, so far it has been very painful.
I am now working on a project that is 70% complete using the PCD compiler and did not want to start all over again with the C30, however maybe that is how I should have started with. I'm using a PIC24HJ256GP206 and so far I seem to have some very perplexing issues.
The main issue I have; is my oscillator which is supposed to be an external 10Mhz crystal, does not work right, and I think I have tried every fuse configuration possible on the PCD compiler. I am using the following:
| Code: |
#fuses PR,XT,NOWDT,DEBUG,NOJTAG,ICSP2,NOPROTECT,NOPUT
|
I was told by CCS support that was correct and it appear to be so for the exception that it sets the oscillator to rc internal first and then to user (according to the fuse settings that I read in MPLAB) what I really want is to start with the user crystal, period!!!
the other thing I notice is the debugger (ICU64)is telling me my crystal frequency is 7.4776 MHz which is very close to the internal 8 MHz RC oscillator, furthermore if you look with a oscilloscope across the crystal I see NO OSCILLATION, just a dc level which tell me that my crystal oscillator is not functioning, obviously it is running on the internal RC 8MHz oscillator,,but the fuse setting are not set for that!!!
If we put aside the oscillator problem, I then have another issue; I can transmit characters over the RS232 port using UART1 with no problem, but for some strange reason, I get garbage characters in, looking at my RXD line with a serial logic analyzer (Thank God for those wonderful tools!!) I can see that my serial stream is correct, but within the PIC it is always garbage. I set out to do further debugging on this issue and found that every character that comes in is in a 8 bit rather than 7 bit format, in other words every character seems to be shifted one bit to the left. So if I send a 'V' (0x56) the PIC receives a weird character or a 0xAC the same occurs for every character received. Perhaps I am missing a very elementary thing here, but I have never seen this before?
If any one can shed any light on this it would be very much  appreciated. (I am using PCD ver 4.087)
Here are portions of my code:
| Code: |
#include <24HJ256GP206.h>
#device *=16
#device ICD=TRUE
#fuses PR,XT,NOWDT,DEBUG,NOJTAG,ICSP2,NOPROTECT,NOPUT
#use delay(clock=10000000,RESTART_WDT) // getting ~ 7.5 MHz instead of 10Mhz
#use rs232(UART1,baud=9600,parity=N,bits=8,)
#int_RDA
void RDA_isr(void)
{ Command = getc();
//Command = U1RXREG; tried this same result
// Command >>=1; // if I do this then the value of the incoming char is ok.....but why?
BufferFlag = 1;
}
void Init(void) // this is my init routines
{
set_tris_g(0x80);
set_tris_f(0xD7);
//setup_spi2(SPI_MASTER | SPI_H_TO_L | SPI_CLK_DIV_4| SPI_XMIT_L_TO_H );
MSTEN = 1; // spi master mode
SMP = 1; // spi sample dat in the middle
CKP = 1; // spi clock iddle state is high
CKE = 0; // spi data changes on transition from active to iddle clock state
PPRE1 = 0; PPRE0 = 1; // Primary prescale 16:1
SPIEN = 1; // enable spi module this should be done last
//setup_wdt(WDT_ON);
setup_wdt(WDT_OFF);
setup_timer1(TMR_INTERNAL|TMR_DIV_BY_1);
setup_adc_ports(ALL_ANALOG);
setup_adc(ADC_CLOCK_DIV_32 );
//enable_interrupts(INT_TIMER1);
disable_interrupts(INT_TIMER1);
//enable_interrupts(INT_TIMER2);
disable_interrupts(INT_TIMER2);
enable_interrupts(INT_RDA);
//enable_interrupts(INT_SI2C);
//enable_interrupts(INT_UART1E);
enable_interrupts(INTR_GLOBAL);
DACSEL1_HIGH; DACSEL2_HIGH;
DACSEL3_HIGH; DACSEL4_HIGH;
DACSEL5_HIGH; IOCSO_HIGH;
IOCS1_HIGH; IOCS2_HIGH;
IORST_HIGH;
}
void main()
{ unsigned int8 ch;
unsigned char v;
unsigned int16 n;
unsigned int16 initvalue = 1000; // 0.5Vout or 100* 0.5 = 50Vout when in CV mode
Init();
printf("Hello world, I hope this will work eventually \n\r"); // this always prints out on the terminal OK
while(1)
{
restart_wdt();
if(BufferFlag)
{ v = Command; //every time I look here at Command it value is incorrect (shifted 1 bit to the left)
delay_cycles(1);
BufferFlag = 0;
}
if(Command == 'V')
printf("OK /n/r");
delay_ms(50);
}
}
|
|
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Apr 23, 2009 11:35 pm |
|
|
PCD has had a lot of (and still has some) bugs, but I didn't yet experience them related to basic UART operation. If I understand your post right, some observations are unclear in your application, e.g. the clock operation. If a considerable deviation of clock frequency exists, faulty UART operation is unevitable, e.g. a bit shift as reported.
I didn't hear from your post, that the clock problems are caused by PCD. Generally it's meaningful to check the actual fuse and SFR settings generated by the compiler against the datasheet. There may be either a misunderstanding on your side or a PCD bug causing the problems. |
|
|
cbarberis
Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA
|
|
| Posted: Fri Apr 24, 2009 5:00 am |
|
|
It appears to me that thre is two separate problems here. Obviously the oscillator problem will certainly affect the serial port comm steam if I use the #use delay(clock=100000000) directive and then use the #use rs232(UART1,baud=9600,Parity=N,bits=8) the actual clock frequency of the system is 7.4776 MHz then when you try sending or receving an async serial stream you will have garbage both ways because your baud rate is completely screwed-up, so if I use #use delay(clock=74776770) the baud frequency will now be OK, the fact is I have not fixed anything. Why is this thing reverting to internal FRC and not work on the external crystal??? I have built 100's of similar boards with PIC's before and I know it is not an issue on the pcb. If we find a solution for this oscillator issue, then I still have a problem with the received serial data, why is this serial data shifted one bit to the left on the receive port and not on the tx port???   |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Fri Apr 24, 2009 6:13 am |
|
|
I supposed a speed mismatch, obviously it has different consequences on TX and RX. But I'm not sure about.
Basically. hardware UART operation is only affecting a SFR (and the global clock, of course), it can be rather easily traced in assembly listing respectively with the debugger, there shouldn't be max room for unrevealed compiler misteries. |
|
|
Guest
|
|
| Posted: Fri Apr 24, 2009 5:58 pm |
|
|
| I think you should have an HT instead of XT #fuses specifier. |
|
|
Guest
|
|
| Posted: Wed Jun 03, 2009 7:15 pm |
|
|
| I had a perfectly working program with version 4.087. When I upgraded to any version higher the program stopped working. The problem was how if statements were tested in float arrays. I went back to 4.087 and the code is now working as before. I'm not upgrading till 4.1 comes out. Hopefully all the bugs will be gone. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Jun 04, 2009 12:10 am |
|
|
There's always a certain risk, that new bugs are introduced in compiler development. Thus it's mainly a question about software testing at CCS. I'm under the impression, that particularly in PCD deveplopment an effective test application, that also includes complex expressions, arrays and combinations of different data types would have revealed most bugs that occured during the last year. Also some bugs, that are still persisting can be reproduced with basic test cases.
| Quote: | | I'm not upgrading till 4.1 comes out. Hopefully all the bugs will be gone. |
Do you imagine, bugs reported 6 months ago, that have apparently never been touched since then, will magically disappear with V4.100? Wonderful. |
|
|
|
|
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
