| View previous topic :: View next topic |
| Author |
Message |
fbct62
Guest
|
| dspic 6012 i2c slave mode not working |
 Posted: Sat Nov 21, 2009 10:48 am |
 |
|
Hello all.
I have problem when use a dspic6012 in i2c slave mode. The dspic not work.
Can anyone help me?.
Thanks.
I have configured in this way:
| Code: |
#include <30f6012A.h>
#fuses FRC_PLL16,NOMCLR
#use delay(clock=117920000)
#use i2c(slave,address=0xA4,sda=PIN_G3,scl=PIN_G2)
#INT_SI2C
void ssp_interupt ()
{
BYTE incoming, state;
state = i2c_isr_state();
if(state < 0x80) //Master is sending data
{
incoming = i2c_read();
if(state == 1) { //First received byte is address
CommandCode = incoming;
}
if (state==2) {
switch (CommandCode) {
case 0x10:StartDecoding=1;break;
}
}
}
if(state >= 0x80) //Master is requesting data
{
}
}
void main()
{
StartDecoding=0;
enable_interrupts(INTR_GLOBAL);
enable_interrupts(INT_SI2C);
while (1) ;
}
|
|
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Nov 21, 2009 11:14 am |
|
|
Can you specify "not working"?
- ACK on the bus, at least on an correct address ?
- Generating any slave interrupts?
- Further observations? |
|
|
FBCT62
Guest
|
|
| Posted: Sat Nov 21, 2009 11:29 am |
|
|
| FvM wrote: | Can you specify "not working"?
- ACK on the bus, at least on an correct address ?
- Generating any slave interrupts?
- Further observations? |
Hi,
In this moment I do not have logic analyzer available, but I control the master in debug mode and it not receive the ack.
The master code is implemented on a Rabbit core module .
This is the code:
| Code: | int StartDvbDeconfig(void )
{
i2c_start_tx();
if (i2c_write_char(0xA4)==0) {
i2c_write_char(0x10); // command code
}
i2c_stop_tx();
}
|
The command code line is not perfomed.
The Rabbit code is correct because I use the same sequence for command other device in the same bus (2 mcp23016, 2 pic18f2550 and one dvbs receiver module).
For this I think that the dspic "not work".
Not generate any interrupt. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Nov 21, 2009 12:18 pm |
|
|
| Yes, sounds plausible. In my understanding, you should get an address ACK, if the SSP module is enabled and configured with the correct slave address. It seemed to me, that SSP is configured correctly with PCD V4.100. What's your compiler version? |
|
|
fbct62
Guest
|
|
| Posted: Sat Nov 21, 2009 12:26 pm |
|
|
Hi,
I'm using a demo version 4.094. I have tried also changing the clock FRC_PLL4, but not work.
Yes probably the SSP module is not properly configured. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Nov 21, 2009 12:42 pm |
|
|
| I don't see an incorrect I2C configuration, I also checked with previous PCD versions. You hopefully verified, that the processor is executing your code, e.g. can blink a LED. |
|
|
fbct62
Guest
|
|
| Posted: Sat Nov 21, 2009 12:52 pm |
|
|
Hi,
The processor work. I have added a serial output string in the loop
and I see the string with hyperterminal.
I try to initialize in this way:
| Code: | | #use i2c(I2C1,slave,address=0xA4) |
|
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Nov 21, 2009 1:48 pm |
|
|
I don't expect a different behaviour from this change, but you can try. I also found, that several silicon errata are
listed for dspic30f6012A SSP module, I'm not sure, if they can affect basic slave operation. One about glitches
on enabling the SSP modules makes it advisable to check SSPSTAT for debug purposes. I would also monitor the
hardware SCL and SDA signals, e.g with an oscilloscope. |
|
|
fbct62
Guest
|
|
| Posted: Sat Nov 21, 2009 3:26 pm |
|
|
Thanks for all FvM.
Monday I analyze the problem with instrumentation. |
|
|
fbct62
Guest
|
|
| Posted: Sat Nov 21, 2009 5:30 pm |
|
|
Hello all.
I have resolved the problem the correct address is 0x52 now work. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Nov 21, 2009 6:06 pm |
|
|
Yes it's the well-known confusion of 7-Bit versus 8-Bit notation of I2C addresses. Microchip is contributing to it by e.g. naming address bits A7..A1 in some documents and A6..A0 in others. Philips/NXP and most manufacturers are however prefering the left justified "0xa4" notation.
I think, CCS is also adding confusion by using an invalid entry of address=0xa0 in the manual. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
