I2C Force_HW not working

[Martin Berriman]

I must be doing something stupid but I cannot seem to get FORCE_HW working.

I am using a PIC with built in MSSP that can operate as I2C master which is what I want (PIC 18F4620).

If I leave out FORCE_HW and let CCS generate SW I2C handler then everything works fine but I could do with reducing the code footprint a bit so changing to HW I2C will save me a few percent. Since it works in SW mode, I am sure I am setting the tristate directions correctly (I'm using FAST_IO) and addressing the varoius I2C devices correctly. I must not be configuring something that I should be but can't seem to see where.

I have tried using setup_spi(SPI_SS_DISABLED) in case it was trying to use the MSSP for SPI but no luck. My program gets stuck at the first I2C_start command waiting for the hardware to say that it has started successfully.

The CCS help file has not shed any light and searching on the forum here for FORCE_HW issues only seems to highlight problems where the PIC being used in not able to act as I2C master (ie no MSSP).

Any thoughts appreciated...
Edit: Forgot to say version 3.249

[ckielstra]

You don't show your #use I2C line, so we don't have enough information to go on.
Or, as always: post a small, complete, compilable example program. Should not be more than 10 lines.

Using setup_spi(SPI_SS_DISABLED) is dangerous as this is an invalid combination of parameters. The official call for disabling SPI is setup_spi(FALSE). I didn't check it, but the sequence for disabling SPI and enabling I2C most likely have some dependencies as they are basically the same hardware unit. I would just leave out the call to setup_spi() at all.

[Martin Berriman]

Ok, here's some simple code. Unless the #use I2C takes care of it, I am obviously missing something to configure the MSSP as I2C... There does not seem to be a setup_i2c function like there is a setup_spi one
The program gets stuck in i2c_write (rather than i2c_start as I said earlier).

[PCM programmer]

When you invoke the hardware i2c library, the compiler inserts start-up
code that configures Pins C3 and C4 as inputs. See the lines shown in
bold below. You're overriding this with your set_tris_c(0x80) statement.

[Martin Berriman]

Thank you PCM Programmer, that works now

I thought that because I was using FAST_IO, I was responsible for setting the pins as inputs or outputs (indeed without FORCE_HW, I am responsible) but it seems that when using FORCE_HW the hardware takes full responsibility for setting those pin directions - so I get the day off .

Having now removed from my code the lines to change the SDA pin direction when reading and writing, and also set both SDA and SCL pins to inputs in the TRIS settings, FORCE_HW works as it should and saves me 3% code space as well.

A note in the CCS help file under FORCE_HW would have saved a lot of trouble here

Thanks again.

[Ttelmah]

Er. This is not a CCS problem.
It is rather bad 'data sheeting' on the chip itself. Microchip, say that the hardware peripheral 'overrides' the I/O pins, and that it is the users responsibility to set the TRIS bits, then gives what to set them for for the slave modes, but not for the master mode. In fact it is only because on a lot of other chips, they give the override circuit, where it is shown that for this section, the pins must be set as inputs, or the output driver will block data reception, that 'older users', will know to try setting the pins as inputs.
If you use 'fast_io', it is up to you to control the TRIS. The initialisation code, is 'residual', CCS, automatically insert it if you have the #use I2C line, whatever I/O mode you specify. If you leave the port in the CCS default 'standard_io' mode, it'll work without you changing anything.

Best Wishes

[ckielstra]

[Martin Berriman]

Thanks guys. I'm glad I was not being completely dim I'll certainly remember this nugget on info in future...