Problem with Digital Pot MCP4017 driving

[Ttelmah]

On the first, are you setting up the pins with pin_select?.
Though the pins 'default' to certain pins, so you can use the I2C2, CCS
has a 'habit' of not knowing the default pins. So though it allows the
selection to be made, it won't correctly setup the TRIS unless you use
#pin select.
Generally, you _must_ setup the pins with #pin_select on PPS ports.
On older compilers it won't let you use the ports, unless the selections are
made. A while ago on some chips the compiler started allowing the port
names top be used, and not warning about this, but for me, it is better
and safer to always select the pins.

[PICmodule]

[PICmodule]

I done the following, declared the SCL and SDA pins

[PICmodule]

I changed also to this

[PICmodule]

I tested any other idea I have had with setup, still the same:

1. with software I2C is not working (hang-up)
2. with hardware is not working (not generating clk)

so for 90% it is compiler bug.
Trying to port I2C from the microchip compiler library, as I must solve it ASAP, production is waiting for me. I can not release it for production until l sure about that.
Best Regards

[Ttelmah]

Understand, that you have a chip with the I2C module, not the normal MSSP.
This module does not support the I2C_WRITE command. Everything has to be
done a s I2C_TRANSFER, which will then automatically send a start, do one
or more writes, optionally reads, and then send a stop.
This module is very much harder to use than the standard MSSP, which
is why using software I2C is the way to go for things like detecting the ACK
on chips with this module. This is why the hardware is not working.

However the software ought to work.

However, you are trying to use options with the software I2C, that don't
exist. You can't specify SMBUS with software I2C. This option is only
available using the hardware. Software I2C can only use the standard buffers
on the pins. No such option.

I must admit the software driver is so basic and simple, that I have never
seen it not work, unless there is something else on the chip interfering
with the pins involved.
Make sure you have turned off the comparator. This has priority over
normal pin operations and often gives problems. Also the CTMU, and
set these pins as digital. These are the three things that have priority
over the normal pin operations, particularly on input.

[PICmodule]

[PICmodule]

I contacted CCS, they confirmed no compiler bug, send me some samples, so testing, hopefully soon will be able to share with you a working and tested examples

[PICmodule]

Hi,
I received a full working example from CCS, they are very helpful.
I run it successfully on the official Microchip PIC24FJ256FA Curiosity Dev
Board. Can see in/out data as also pulses on the SCL. Tomorrow I will implement it on my PCB, and after that release to public the working example. So, there is no bug in the compiler.
Thank you all of yours for suggestions and help.
Best Regards

[PICmodule]

Hi,
So, the reason was the hardware !
I fixed it working with Microchip PIC24FJ256GA Development Board.
I soldered the MCP4017 to it and test. When MCP4017 is powered with 5V (allowed by manufacturer 1V8-5V5) and read by 3V3 system (PIC24FJ256GA) it is not working. Even if the I have the pullup resistors connected to the 3V3, so only powering the MCP4017 with 5V5. No way. Not working. If switch powering to 3V3, still connected pull-up resistors (4K7) to 3V3, working perfectly. On my opinion should work.
Thank you for your suggestions and help
Best Regards

[Ttelmah]

That is 'classic'. Basically 99% of the time when mixing 3.3v devices with 5v
peripherals the signals from the peripheral will not go high enough to meet
the input requirements of the 3.3v device.
The funny thing was I took the time at the weekend to write some basic
test code to see how the I2C ran with this chip, and was going to post back
this morning, that as far as I could see, certainly the software I2C it should
run, and the only time I could get it to 'hang', was when the SCL signal
was not actually going high enough. The code releases this line, and then
loops if it is not seen as 'high' by the chip input.
Glad you have it working now.

[PICmodule]

I release this simple code tomorrow, now in hurry to send system to manufacture PCB, and then assembly. The original library sent from CCS can not share as it is under CCS license, so I will write my own and then share here. This bug cost me 4-5 days until fixed it. But OK, better late than never.
I'm fanatic user of CCS as using it since 2004.
Thank you again.
BR

[temtronic]

GREAT that you FOUND the reason and got it working !!!
I never thought about mixed voltages as I'd assumed you were powering the device with the same VDD as the PIC.
Since today most 'peripheral' devices are 3 volts, I suggest using a 3 volt PIC. Most PICs have an 'LF' version, 'L' being low voltage, and some, like the 18F46K22 have a wide voltage range, so it'll directly interface with EITHER 3v or 5V devices. It's critical to read the 'electrical' specs and charts, not all PICs are the same though !!
I would think that most products today actually run with a 3V VDD, especially those using batteries. If you need to have mixed VDDs, then you'll have to have proper 'logic level' translation devices between PIC and peripheral to be 100% sure a '1' is a '1'.

[PICmodule]

In the i2c in theory we do not need to care about that. This is because we have open drain I/O ins SDA and SCL, and that is the reason we are using pull up resistors that must be pulled up to "other side" interface voltage. This what I
done. But this is theory, in practice not :-)
BR

[gaugeguy]

I2C level shifters or I2C level translators are very common and are almost always required when working with different voltage supplies. These circuits are available both as discrete components and integrated circuits. A google search will show you examples from numerous sources.