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 Previous  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
Ttelmah



Joined: 11 Mar 2010
Posts: 17468

View user's profile Send private message

PostPosted: Tue Oct 26, 2021 11:39 pm     Reply with quote

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



Joined: 26 Oct 2021
Posts: 19

View user's profile Send private message

PostPosted: Wed Oct 27, 2021 12:39 am     Reply with quote

Ttelmah wrote:
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.

Hi,
Thank you for your comment !
I would be happy to make the #pin_select, but there is no such command for the I2C, I check it many times in the manual and help. Nothing.
As far I understand the I2C HW automatically select the proper pins.
Do you know how to make non automatic pin selection?
I sent email to CCS support but no answered yet, but OK only 12 hours passed, so not too bad
Any idea or help would strongly appreciated
I installed also the former compiler version to see if effects are the same 5.094 but behavior is the same
Thank you in advance for ANY idea or guidelines
BR
PICmodule



Joined: 26 Oct 2021
Posts: 19

View user's profile Send private message

PostPosted: Wed Oct 27, 2021 12:48 am     Reply with quote

I done the following, declared the SCL and SDA pins

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


but still nothing, same effect every second address I have response
I do not have anything else except of resistors on this I2C bus
Best Regards
PICmodule



Joined: 26 Oct 2021
Posts: 19

View user's profile Send private message

PostPosted: Wed Oct 27, 2021 12:50 am     Reply with quote

I changed also to this

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

removed the I2C1 and added the FORCE_HW, but same effect
PICmodule



Joined: 26 Oct 2021
Posts: 19

View user's profile Send private message

PostPosted: Wed Oct 27, 2021 1:14 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 17468

View user's profile Send private message

PostPosted: Wed Oct 27, 2021 3:34 am     Reply with quote

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



Joined: 26 Oct 2021
Posts: 19

View user's profile Send private message

PostPosted: Wed Oct 27, 2021 3:44 am     Reply with quote

Ttelmah wrote:
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.


Thank you for your comments and help!! I'm anonymously monitoring your post over this forum years and found them always very valuable.
Here what I'm using:
Compiler Version: 5.105
Controller: PIC24FJ128GA705
Yes, it has INTER-INTEGRATED CIRCUIT (I2C)
I will follow your suggestions and come back hopefully soon.

Thank you again for your time.
Best Regards
PICmodule



Joined: 26 Oct 2021
Posts: 19

View user's profile Send private message

PostPosted: Wed Oct 27, 2021 2:09 pm     Reply with quote

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



Joined: 26 Oct 2021
Posts: 19

View user's profile Send private message

PostPosted: Thu Oct 28, 2021 3:59 pm     Reply with quote

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



Joined: 26 Oct 2021
Posts: 19

View user's profile Send private message

PostPosted: Mon Nov 01, 2021 2:08 am     Reply with quote

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


Last edited by PICmodule on Mon Nov 01, 2021 4:59 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 17468

View user's profile Send private message

PostPosted: Mon Nov 01, 2021 4:44 am     Reply with quote

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



Joined: 26 Oct 2021
Posts: 19

View user's profile Send private message

PostPosted: Mon Nov 01, 2021 4:58 am     Reply with quote

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



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

View user's profile Send private message

PostPosted: Mon Nov 01, 2021 5:17 am     Reply with quote

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



Joined: 26 Oct 2021
Posts: 19

View user's profile Send private message

PostPosted: Mon Nov 01, 2021 5:23 am     Reply with quote

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



Joined: 05 Apr 2011
Posts: 200

View user's profile Send private message

PostPosted: Mon Nov 01, 2021 6:55 am     Reply with quote

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.
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 Previous  1, 2, 3  Next
Page 2 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