I2C on PIC18F27Q43

[devau]

I have changed now the address in the code from 0x4E to 0x9C
(On the LCD's PCF8574?: This can't be done, as there's only jumpers for the A0,A1,A2 bits.)

This is what I used:
//#pin_select SDA1=PIN_B2 leave commented out, else compiler says*** Error 7, Invalid Pre-Processor directive Pin already used
//#pin_select SCL1=PIN_B1 leave commented out, else compiler says*** Error 7, Invalid Pre-Processor directive Pin already used

#pin_select SDA1IN=PIN_B2
#pin_select SDA1OUT=PIN_B2
#pin_select SCL1IN=PIN_B1
#pin_select SCL1OUT=PIN_B1

#use i2c(Master,I2C1,fast=100000,sda=PIN_B2,scl=PIN_B1,force_hw,STREAM=LCD)

set_open_drain_b(0B00000110); // B1 B2
set_tris_B(0B00000000);

Processor hangs after this line:
i2c_transfer_out(LCD, (uint8_t) LCD_ADDRESS, buffer, 1);

[devau]

"The PIC18F27Q43 no longer uses the old MSSP module; instead, it features a completely redesigned, dedicated I2C hardware module. Regarding addressing, this module strictly adheres to the 7-bit format. Here is the precise breakdown of how your address is composed and why 0x9C would be incorrect: 1. The mathematical misunderstanding regarding 0x9C. If you have a generic LCD board based on the PCF8574 (TI style), the 7-bit base address is 0x27. If you shift 0x27 left by one bit (0x27 << 1), you get 0x4E (or 0x4F for a read operation). Where does the value 0x9C come from? That would be the result of shifting 0x4E to the left (0x4E << 1 = 0x9C). In this case, a double shift has occurred, rendering the address completely unusable on the bus."

Anyway: Wrong addresses should never make the PIC hanging. I think the error lies in the CCS Compiler itself (used version is 5.119). As I said: I gave up. Using software method:
#use i2c(Master, Fast, sda=PIN_B2, scl=PIN_B1, STREAM=LCD)
works flawlessly :-)

[Ttelmah]

OK.
The point was you said that it wanted address 4E from its data sheet. It sounds as if you have already shifted this from the TI address?.
However 4E suggests this is a unit using the TI I/O expander?.

If so, the first thing is to get rid of the pin definitions in your
#USE I2C:

[devau]

in your #iuse... line the keyword "force_hw" is missing. Without it, CCS assumes software mode.
I compiled it now with "force_hw". And to be sure, I used:
uint8_t buffer = 0x00;
And still the PIC hangs at the i2c_transfer call.

[Ttelmah]

No. If you use the hardware port name (I2C1), this automatically forces
the use hardware selection.

The only reason that will hang, is if is is not getting an ACK from the attached
device.

[devau]

[Woody]

The CCS compiler might not be without its flaws but so far most problems I ran into were due to a lack of understanding on my part :-)

Your compiler version is way newer than the one I used in my example above here, and my code runs without problems for years now. Never 'hangs' the CPU.

What I see as strange in your code is in your

[Ttelmah]

I did try using the I2C peripheral on a Q43, talking to a EEPROM, and it merrily
worked OK with the current function.
However it is well worth saying that the software I2C for the master is
often more reliable, and just as fast on many modern chips. The nice
thing is the functions are more forgiving than the peripheral is.....

[asmallri]

[Ttelmah]

Yes.
Very true.

Sometimes the problem can be one that you have no control over though.
I've seen a couple of chips, which if you put a logic analyser on the timings
do things that are technically not compliant with I2C specs, and on one
of these at least, the software I2C implementation allowed it to work.

[Woody]

I find this an interesting discussion. Instinctively to me the HW implementation would always be better as this uses the module that Microchip specially made for that purpose, in contrast to the bit-banging of the CCS SW implementation. But reading this thread there are indications the SW implementation would be better?

The CCS HW implementation leaves something to be desired. At the moment I'm working on a project that is to become an I2C client. A quite basic client that controls a small DC motor assembly with a couple of one-byte commands. No requests for status code returns (yet:)

I used the CCS example EX_SLAVE_K42.C as a start but could not get that to function reliably. It did receive commands, but it kept on hanging the I2C module whenever I sent illegal addresses or too many data fields from the master (an Aardvark) to the client.

I then decided to forsake the #INT_I2C driven i2c_isr_state() and i2c_read() statements and try to roll my own. A very simple interrupt routine for #INT_I2C1RX that only reads I2C1RXB whenever there is data in RXBF seems to have solved this for me. Now I can fire any address or extra data on the bus without hanging the client I2C module.

This makes me think that either I misunderstand the way these CCS I2C functions work (happens a lot) or that these functions do not work optimally with the new I2C modules.

[asmallri]

Well... I always use HW where it exists and the ports are available. When building a device / product that must run reliably and be able to recover itself then I build the ability into the product to either power cycle the power to all I2C slave devices or, if the the slaves are all PICs and, if possible, a common reset line under the control of the master to reset all slave PICs

I find the slave problem is the most difficult to address. When recovering the I2C bus or busses I also do a bit toggle I2C bus sequence during the recovery process before enabling the I2C master peripheral.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!