ANSELC = 0;
ANSELB = 0;
TRISB.F6 = 1; //set port b bit 6 to input
TRISB.F7 = 1; //set port b bit 7 to input
TRISC.F7 = 1; //set port c bit 7 to input
TRISC.F3 = 0; //i2c ports to output
TRISC.F4 = 0;
I2C1_Init(100000);
Delay_ms(125);
//reset
iic_wr(2, 0xc282);
//enable
iic_wr(2, 0xc281);
iic_wr(5, 0x8c84);
//60.0-115.0Mhz
iic_wr(0x53, 650);
iic_wr(0x54, 1150);
//transmit
iic_wr(0x40, 1);
iic_wr(0x3, 0x525c); // 97.9
void iic_wr(unsigned char addr, unsigned int dat)
{
I2C1_Start();
I2C1_Wr(0x22);
I2C1_Wr(addr);
Delay_ms(1);
I2C1_Wr(dat>>8);
I2C1_Wr((unsigned char)dat);
I2C1_Stop();
Delay_ms(125);
}
If you don't have a debugger, I suppose that you don't have a scope either! IT would have been very useful to see the signals and to make sure that they were well formed etc..
I'm sure that is not all of your code!
What oscillator source are you using? What frequency is the oscillator?
If you don't have a debugger, how do you know that the device is 'halt'ing? Also, do you really "halt" or do you mean a tight loop or what?
I assume that you have all of the bypass capacitors in place, that the \MCLR\ pin is held high (or disabled in the config settings). Is the programmer still connected when you try to run the code?
I assume that you have the "MODE" pin on the RDA5820 held low?
On that, have you tried using the SPI interface instead? It can be simpler (no ACK etc in the command signals) and is also a bit easier to drive from your software. If you can show that the SPI interface works then it would help to narrow down the problems.
(It is statements such as this that are the reason I ask to see all of the code, including the configuration settings.)The oscillator crystal is 32.768khz. Is it ok to use an i2c bus frequency greater than this speed (I'm using 100khz)?
(It is statements such as this that are the reason I ask to see all of the code, including the configuration settings.)
The I2C baud rate generator (as described in Section 15.7 of the PIC18F26K22 data sheet) cannot run faster that Fosc/4 (and there is also the division by (SSPxADD+1) in there as well). Therefore to achieve 100kHz you must be getting Fosc to be at least 400kHz.
The PIC must have the bypass capacitors (as must any such IC). Depending on how good your power supply is, even if there is plenty of current available, the switching transients caused by a MCU at high speed (although I accept that it sounds like your is running very slowly) can cause all sorts of 'strange' behaviours.
I'm surprised that you say you cannot use mikroC to debug your code - looking at Chapter 3 of a mikroC User Guide I found on the Internet, Chapter 3 is all about how to debug through the mikroC IDE. As I say, I really have no experience in this area.
SSPCON1.F5 = 1; // Synchronous Serial Port Enable(I2C)
SSPCON1.F3 = 1,SSPCON1.F2 = 0,SSPCON1.F1 = 0,SSPCON1.F0 = 0; //I2C in master mode
I'm sorry but I don't understand what you mean by "it was SSPCON". (For a start, there are 3 SSPxCONy registers where x refers to which of the MSSP peripherals you are using and y is form 1 to 3 depending on which register you are referring to. I assume this is some sort of non-standards register and bit renaming that MikroC use that differs from the data sheet!)
Or are you saying that EMI on the SCK and SDA lines was high enough to mean the voltage transitions were leading to incorrect detection of a transition (from '0' to '1' or '1' to '0')? If so then it si NOT a register prob elm but an EMI problem.
As you are assign about EMI shielding, the answer is to use some form of shielded cables.
HOWEVER, that also probably means that you have significant other physical design issues such as cables that are too long, intermodulation between the SCK snd SDA lines and so on. You have not mentioned anything about the physical layout so it is hard to tell.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?