CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

HELP with dsPIC running on I2C Slave mode

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
cbarberis



Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA

View user's profile Send private message Send e-mail

HELP with dsPIC running on I2C Slave mode
PostPosted: Sat Feb 16, 2013 6:31 pm     Reply with quote

Hopefully, some smart person will see whatever stupid thing I am doing wrong. I am trying to send some data via I2C from one PIC to another. In this case just for testing, I'm using a PIC184520 as the master, all the master does is just send two bytes, the first one with the address of the slave (dsPIC33JF12GP201) and the W/R on the LSB and the next following byte contains 8 bits of data. This is part of a high voltage controller design, where the dsPIC does the high voltage control via the I2C bus.
I have done this many times in the past with PIC18 series of devices with great success, but for some reason it does not want to work with the dsPIC device. I am using PCD V4.140 which is the latest compiler version. Basically, what is happening (or not happening) is that the master device sends the two bytes via I2C to the dsPIC and the dsPIC (slave) then gathers this information and performs a PID control loop on a HV supply. Simply put, what is not happening here is that the I2C interrupt on the slave device never takes place, I have tried everything possible to no avail. It may be me or it may be CCS but in either case it does not work and I just don't want to re-write the whole thing on MPLAB C30.


This is the code for the MASTER:
Code:

#include <main.h>

#define SLAVEADDRESSW 0x0C // slave address when writing
#define SLAVEADDRESSR 13 // slave address when reading


unsigned int commandvalue =25;

void Init()
{
   setup_adc_ports(NO_ANALOGS);
   setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
   //setup_oscillator(OSC_8MHZ|OSC_TIMER1|OSC_31250|OSC_PLL_OFF);
   setup_wdt(WDT_OFF);
}


void main()
{
  Init();
  delay_ms(1000);///wait a sec so slave can be set up
 
 
  while(1){
 
             if(!input(PIN_D0))    /// we press a switch here and just send some data to the slave
             { commandvalue += 5;
               i2c_start();
               i2c_write(SLAVEADDRESSW); 
               i2c_write(commandvalue);       
               i2c_stop(); }
               
               output_high(PIN_D3);  ///this is just to make sure this puppy is running
               delay_ms(100);
               output_low(PIN_D3);
               delay_ms(100);
               
   restart_wdt(); 
  }
}

The code below is for the SLAVE:
Code:

#include <33FJ12GP201.h>
#device *=16
#device ICD = 1

#FUSES FRC,NOWDT,CKSFSM,NOJTAG,DEBUG       
#use delay(clock=7.37MHz,RESTART_WDT)

#pin_select OC1 = PIN_B4

#use i2c(i2c1,Slave,slow,force_hw,address=0x0C)

#define HVCONTROL PIN_B7
#define HVON output_low(PIN_B15)
#define HVOFF output_high(PIN_B15)
#define SLAVEADDRESSW 0xC // slave address when writing
#define SLAVEADDRESSR 0xD // slave address when reading 
#define COMMANDBYTE 0x80
#define I2CBUFFER_SIZE 3

unsigned int8 Rxbuffer[I2CBUFFER_SIZE];
unsigned int8 Txbuffer[I2CBUFFER_SIZE];
unsigned int8 state,incoming,address;
int1 I2CReceiveFlag = 0;
int1 ActiveFlag = 0;
unsigned int8 CommandValue;
unsigned int8 SetPointValue = 0;


///#include "C:\PICOMP\FILES\Sage\NewPippinsPulsePSC\PID.C" //


#int_EXT0
void  EXT0_isr(void)
{
  ;;
}

#INT_SI2C
void  i2c_isr(void)
{
   state = i2c_isr_state();
   if(state < COMMANDBYTE)        //Master is sending data to us
   {  incoming = i2c_read();      // Get I2C data byte

    switch (state) {              // Filter out individual bytes
    case 0:                       // if state is zero then we have the first byte = Address Byte and R/W bit direction
    address = incoming;
    break;
    case 1:                       // if state is one then we have the second byte or first data byte
    Rxbuffer[0] = incoming;
    break;
    case 2:                      // if state is two then we have the third byte or second data byte NOT USED at the moment
    Rxbuffer[1] = incoming;
    break;  }
   
   if(state == 1)             // if we got all data bytes that we need
   I2CReceiveFlag = 1;        // Set the flag so we can process the entire data transfer
}
}


void Init(){
 //RB8_TRIS =1;
 //RB9_TRIS =1;
 setup_compare(1,COMPARE_PWM | COMPARE_TIMER2 );
 setup_timer2(TMR_INTERNAL | TMR_DIV_BY_1,1024 );
 setup_adc_ports(sAN0);
 setup_adc(ADC_CLOCK_INTERNAL | ADC_TAD_MUL_4);
 setup_timer1(TMR_DISABLED|TMR_DIV_BY_1);
 HVOFF;
 set_pwm_duty(1,0);
 set_adc_channel(0);
 //A10M = 0;
 //enable_interrupts(INT_EXT0);
 enable_interrupts(INT_SI2C);
 enable_interrupts(INTR_GLOBAL);
}




void main()
{  unsigned int Reading;

   Init();
   
   while(1){
     
       if(I2CReceiveFlag)           // Process incoming I2C commands
      { SetPointValue = Rxbuffer[0];
        output_low(PIN_B14);
         I2CReceiveFlag = 0; }
 
 
      if(!input(HVCONTROL))
         { HVON;
            ActiveFlag = 1;}
      else   
          { HVOFF;
           ActiveFlag = 0;}
 
      ControlSetpoint = (float)SetPointValue;
       
        pid();

       //Reading = read_adc();
       
        delay_ms(SAMPLETIME);
       
        restart_wdt();     
     
 }  }
cbarberis



Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA

View user's profile Send private message Send e-mail

PostPosted: Sun Feb 17, 2013 9:39 pm     Reply with quote

Amazingly enough after many hours of playing with this I have got it to work but there is something that I truly don't seem to understand. It appears that changing the slave address on both the master and slave to an address of 0x10 works ok, however addresses like 0x08 or 0x0C do not work!..Now I know these are valid addresses for 7 bit slave command bytes, so I don't really understand what is really happening, at least not with clarity. In the previous code I posted I show the parameter "slow" on the #use i2c() statement, this should not be there and had nothing to do with the original problem. Another thing to be said about debugging this; originally I tried using Proteus ISIS to do the simulation and debugging, unfortunately the results I got sent me in the wrong direction as I waisted many precious hours trying to debug this. I finally built a breadboard with the actual parts and finally got it to work (Proteus still tells me it does not work)
Perhaps someone can shed some light on such subject Embarassed Rolling Eyes
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sun Feb 17, 2013 10:02 pm     Reply with quote

They are not valid. They are reserved. Look in the table in the upper
left corner on page 16 of the i2c Spec:
www.nxp.com/documents/other/39340011.pdf
It shows that addresses 0x08 and 0x0C are reserved for "Hs-mode master code".

Note: The table shows 7-bit slave addresses, so just add a zero onto
the right side to convert it to CCS 8-bit format. An "X" means "don't
care" which means that bit can be 0 or 1.
cbarberis



Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA

View user's profile Send private message Send e-mail

PostPosted: Mon Feb 18, 2013 7:58 am     Reply with quote

Thank you PCM programmer! But I am still somewhat confused about these addressing limitations. According to a very good piece of info I found here a while back, see:
http://www.totalphase.com/support/kb/10039/#8bit
The address I was using should be OK, well, I should re-state not "should" but it is. I have been using address 0x08 for a slave device that has been in production for more than two years and it works just fine. According to the above literature valid addresses for slaves using 7bit are from 0x08 to 0x77. Perhaps I am still misinterpreting the rules, I guess my question now is, are the so called "reserved addresses" addresses that you are not supposed to use, but however if you use them the hardware will work anyway or are these addresses which the hardware will determine not to be utilized and will not work?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Feb 18, 2013 1:45 pm     Reply with quote

It doesn't matter what some 3rd party website says. What matters is:
1. The Philips i2c spec.
2. The Microchip documentation.

Download the i2c part of the Microchip Reference manual:

Section 19. Inter-Integrated Circuitâ„¢
ww1.microchip.com/downloads/en/DeviceDoc/70195E.pdf
Look on page 37 and you'll find a table of Reserved Addresses.
It's the same table as in the Philips i2c spec. The paragraph
above the table says bluntly that these addresses will be ignored
and the PIC will not issue an Ack.

Now it may be that in some other PIC you got away with it. Perhaps
those addresses weren't properly locked out by silicon design of the
MSSP module. But a very important rule in electronics is "don't violate
a spec".
cbarberis



Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA

View user's profile Send private message Send e-mail

PostPosted: Mon Feb 18, 2013 2:45 pm     Reply with quote

OK, I have read the Microchip document you referred to and it appears to be "the law" if it is masked in silicon thou shall not violate it!
Based on the table of addresses I saw one comes to the conclusion you can only use slave addresses from 0x10 - 0xE0 (using seven bit addressing) is that correct?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Feb 18, 2013 3:21 pm     Reply with quote

The allowable i2c slave base address range is 0x10 through 0xEE.
Those are 8-bit addresses.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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