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 do. I just don't have access to it right now. I'll take a look at it as soon as I can.
I'm sure that is not all of your code!
That's correct, but it is all of the i2c code. It is also the first code that is executed (nothing before it). All the other code has to do with 2x16 LCD communication.
What oscillator source are you using? What frequency is the oscillator?
The oscillator crystal is 32.768khz. Is it ok to use an i2c bus frequency greater than this speed (I'm using 100khz)?
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?
Well, all I know is that after the code I posted there is a line that outputs text to my LCD and whenever the RDA is not initialized, the text is not displayed. There are no loops or anything fancy for it to get caught in (in the internal mikroC libraries there may be).
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 have a bypass capacitor on the RDA, but none on the PIC. Not 100% sure about the MCLR - I'll check that. The programmer is still connected. I'm using the pickit3 and I'm using it as the power source as well.
(I know this might mean I have a debugger, but I use mikroC so I can't use it with that.)
I assume that you have the "MODE" pin on the RDA5820 held low?
Thanks for the help. I can see you looked deep.
I'm sure it is. One reason is because I've tested other chips in place of the RDA that only have i2c communication and they have the same problem. The RDA I'm using is actually mounted on a module from china. The module does not contain any components other than the RDA and the 32khz crystal. It is used just to make experimentation on the breadboard easier. The problem is this MODE pin is not exposed to the module. I asked the chinese though, and they said that it is set for i2c by default (so that sounds like the MODE pin must be low), but I can't verify because it's not exposed and the pin is far too small to probe directly on the RDA.
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.
No, I haven't and I don't think it would be possible to put the MODE pin high because of above.