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

Problem with Digital Pot MCP4017 driving
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
PICmodule



Joined: 26 Oct 2021
Posts: 32

View user's profile Send private message

Problem with Digital Pot MCP4017 driving
PostPosted: Tue Oct 26, 2021 12:59 am     Reply with quote

Hi,
I'm trying to handle the Digital Potentiometer however have some problems. I do not know if it is the I2C itself or something else.

Compiler Version: 5.105
Controller: PIC24FJ128GA705
I tried HW I2C, but no results.
I tried the SF I2C, but no results.
I testing if pins are alive and connected to the proper pins of the MCP4017 just by sending sqr wave to each one, and looks like correct. I have connected 4K7k Resistors to 3V3 on both.

Now trying to multiple sending of the I2C requests to see CLK by DSO


Code:


//PICO_SDA         PIN_B2
//PICO_SCL         PIN_B3
#use i2c(MASTER, SCL=PIN_B3, SDA=PIN_B2, SLOW, RESTART_WDT, stream=A_I2C)
//#use i2c(MASTER, I2C2, SLOW, SMBUS, stream=A_I2C)

-----

      printf("\n\rData Testing Start");
      int8 write_data[] = {0x0}; //select register 28
      int8 read_data[1];
      while(1)
      {
         i2c_transfer(A_I2C, 0b01011110, write_data, 0b01011111, read_data, 1);
         printf("\n\rPOT DATA READ:%x\n\r", read_data[1]);
      }




But system hang up. Any idea from your brains?
Thank you in Advance
MikeW



Joined: 15 Sep 2003
Posts: 184
Location: Warrington UK

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 1:12 am     Reply with quote

4K7 is a bit high. Thats fine for 5V, but I would use 3K3 for 3 volts
PICmodule



Joined: 26 Oct 2021
Posts: 32

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 1:14 am     Reply with quote

Hi,
Yes, but this can not be the reason. I change them to smaller one. But I can not see any clocking
Thank you and Kind Regards
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 1:38 am     Reply with quote

Here are your function parameters lined up with the CCS manual
parameters.
Code:

i2c_transfer(A_I2C, 0b01011110, write_data, 0b01011111, read_data, 1);
                   
i2c_transfer([stream], address, wData,      wCount,     [rData], [rCount]);

You are putting the slave's read address (0x5F) in the wCount
parameter. That's not right.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 5:05 am     Reply with quote

With every I2C device, I use PCM P's 'I2C scanner' program that's in the code library before trying my code.
It'll find and report any I2C device and it's address.
Very handy, QUICK way to confirm you've got HW right, especially the device address !
PICmodule



Joined: 26 Oct 2021
Posts: 32

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 5:15 am     Reply with quote

Hi,
Yes, I know, but trying it find it, and there ware so many solutions. Can you please share with me the link to the proper post with it. Thank you in advance
Kind Regards
PICmodule



Joined: 26 Oct 2021
Posts: 32

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 6:15 am     Reply with quote

Thank you, I found the proper one, and testing with software I2C, but results bad, seems much more IC found than exists. Found 112 devices :-)

It is reporting ACK every second address.
Going to check with DSO, however I tested separately each PIN and works fine
was generating sqr wave on each one.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 9:56 am     Reply with quote

hmm, never ever had that happen....
Are you SURE that clock and data of the PIC are connected to the clock and data of the MCP2017, and not data and clock ? It seems really odd.

Also, whenever testing, be sure to DISABLE the WDT ! There's zero need for it until the product is ready to be shipped out to the client.
PICmodule



Joined: 26 Oct 2021
Posts: 32

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 9:56 am     Reply with quote

update
I de-soldered the digital pot, pins are high (due to resistors).
If send sqr wave from controller are running well, therefore pins are connected to the IC and not shorted.
But still receiving the same, every second address is recognized as IC I2C.
I can not see any clk by DSO or data.

BR
PICmodule



Joined: 26 Oct 2021
Posts: 32

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 10:00 am     Reply with quote

temtronic wrote:
hmm, never ever had that happen....
Are you SURE that clock and data of the PIC are connected to the clock and data of the MCP2017, and not data and clock ? It seems really odd.

Also, whenever testing, be sure to DISABLE the WDT ! There's zero need for it until the product is ready to be shipped out to the client.


I even switched to software I2C so have the ability to reverse pins, no way.
See below my I2C setup:

//PICO_SDA PIN_B2
//PICO_SCL PIN_B3
#use i2c(MASTER, SCL=PIN_B3, SDA=PIN_B2, SLOW, RESTART_WDT, stream=A_I2C)



BR
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 10:17 am     Reply with quote

The code only tests alternate addresses, since each device should/will
be on two addresses (for the read and write interface). It also doesn't
test the reserved addresses (<16).
The ACK, is the bus being held low. You would get an ACK on every
device, it the bus is not being pulled up properly or something is preventing
the bus going up properly.
Now you are using pins with Schmitt trigger inputs, so they will need to
go up to 2.64v before the line will be seen as high.
With the stream name specified in your setup, this should also be used
in the scanner program writes.
PICmodule



Joined: 26 Oct 2021
Posts: 32

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 11:26 am     Reply with quote

Ttelmah thank you for your post.
I again checked the pins, controller and PCB connection, by sending sqr wave to the pins related to the digital pot. I de-soldered it and there are nothing else on the connectivity between controller and digital pot pins (of course pull up resistors are).
I generated sqr wave and these are visible on both pins.
If using I2C SW or HW no clocking on this pins at all.
It seems to me as software problem, probably compiler.
Code:

      while(1)
      {
         output_toggle(PIN_B3);
         output_toggle(PIN_B2);
         delay_ms(10);
      } 

more news when fixed it
BR
gaugeguy



Joined: 05 Apr 2011
Posts: 286

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 11:50 am     Reply with quote

Instead of output_toggle why not use something that simulates the way I2C works. I would also have them opposite polarity to check against shorts between the two.

Code:

while(1)
{
output_low(PIN_B3);
output_float(PIN_B2);
delay_ms(10);
output_float(PIN_B3);
output_low(PIN_B2);
delay_ms(10);
}
PICmodule



Joined: 26 Oct 2021
Posts: 32

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 1:43 pm     Reply with quote

gaugeguy wrote:
Instead of output_toggle why not use something that simulates the way I2C works. I would also have them opposite polarity to check against shorts between the two.

Code:

while(1)
{
output_low(PIN_B3);
output_float(PIN_B2);
delay_ms(10);
output_float(PIN_B3);
output_low(PIN_B2);
delay_ms(10);
}


Hi, working properly also with your code. Hardware is fine. Must be software matter, and rather compiler
BR
PICmodule



Joined: 26 Oct 2021
Posts: 32

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 2:54 pm     Reply with quote

Hi,

There is possible bug in I2C the version of Compiler 5.105 in PIC24FJ128GA705

If set hardware I2C like this

Code:
#use i2c(MASTER, I2C2, SLOW, SMBUS, stream=PICO_I2C)


the below handler is not working at all. No Clock, no data

Code:
int8 get_ack_status(int8 address)
{
int8 status;

    i2c_start(PICO_I2C);
    status = i2c_write(PICO_I2C, address);  // Status = 0 if got an ACK
    i2c_stop(PICO_I2C);
   
    if(status == 0)
       return(TRUE);
    else
       return(FALSE);
}


If set I2C as a software like this

Code:
#use i2c(MASTER, SCL=PIN_B3, SDA=PIN_B2, FORCE_SW, SLOW, SMBUS, stream=PICO_I2C)


the below handler is partially working clock and data but only partially

Code:
int8 get_ack_status(int8 address)
{
int8 status;

    i2c_start(PICO_I2C);


on the below is hang-up here

Code:
status = i2c_write(PICO_I2C, address);  // Status = 0 if got an ACK


sent already question to CCS
BR
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
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