i2c issue after a long absence

[Fusillade]

I last used my CCS compiler in Oct of 2012. Program has been running great for 5 1/2 years. A customer needs a special modification so I renewed my license, download the latest version of CCS PCWH, upgraded to MPLAB X, converted the project, and finally recompiled my old files with the new compiler. The program will not run.

I reflashed with original hex file, runs great.

I reflash again with new hex file, will not run.

Rolled back to MPLAB 8, recompiled with new compiler, will not run.

Created a project in the CCS IDE, recompiled with new compiler, will not run.

Compared all three hex files created with new compiler using three different IDEs. With the exception of the creation time stamp at the end of the file, they are identical.

Loaded the new hex file into the Microchip IPE and verified that the config registers are the same between my old file and new file, identical.

Ran debug in MPLAB X and the program starts but hangs on:

#use i2c(master, sda=TEMP_SDA, scl=TEMP_SCL)

Commented out my initialization of the I2C and program continues as I can now read data I placed in the EEPROM.

I read the manual, saw no changes in '#use i2c' usage. Looked at the assembly listing and there have been significant changes in the code created upon a call to '#use i2c'. Code created for calls to '#use rs232' and '#use delay' have not changed.

Has there been a significant change in the I2C module over the past 5 1/2 years that I'm not aware of that might affect older code?
_________________
New:

Compiler Version: 5.078
IDE Version: MPLAB X V4.15
Devices: PIC18LF****

Old:

Compiler Version: 4.121
IDE Version: MPLAB IDE V8.63
Devices: PIC18LF****

[PCM programmer]

1. Tell us the full part number of the PIC that you're currently using and
also the one that you used in the past.

2. Tell us the Vdd voltage of the PIC (then and now), and the i2c pull-up
voltage, and the Vdd of the i2c slave.

3. Post the pull-up resistors value.

4. Tell us the actual pin numbers used for i2c (then and now).
For example, PIN_C3 and PIN_C4 for SCL and SDA.

5. Tell us the oscillator frequency of the PIC, i.e., the value used in
#use delay(clock= ).

6. Tell us what the i2c slave chip is, and how many of them are on the
same i2c bus.

[temtronic]

hmmm.
A customer needs a special modification so I renewed my license,

Since the old code worked fine, what is the 'special modification' ? Is it hardware or software ?
Now assuming ALL the hardware is as it was 6 years ago, that points to a software problem.
Have to ask, why the upgrade?, assuming a software 'special modifcation', why couldn't you use the old compiler version as well as the programmer or IDE program?

If you've made a hardware change, run PCM Ps 'I2C Scanner' program and report if it sees the I2C devices at their correct addreses.
Does this fail on only one PCB and/or one PIC ?

[Ttelmah]

There is one critical difference in #USE I2C.

Back at 4.121, software I2C was the default even if the hardware pins were used. With V5 compilers this was changed, and hardware I2C will be used if the hardware pins are selected.

It looks like your old code was using software I2C, and probably therefore a slower I2C rate. The new code is using the hardware peripheral.

#use i2c(master, sda=TEMP_SDA, scl=TEMP_SCL, FORCE_SW)

Should make it function like the old code.

You may well find it works OK, if you simply limit the clock rate. So:

#use i2c(master, sda=TEMP_SDA, scl=TEMP_SCL, SLOW)

The manual does give the clue for this. The old V4 manual:

[Fusillade]

[Fusillade]

[PCM programmer]

[Ttelmah]

and with 47K, I'd be lowering the clock rate even further. So:
#use i2c(master, sda=TEMP_SDA, scl=TEMP_SCL, slow=50000, FORCE_SW)

Honestly, 47K, is so high that I'd doubt if the bus can meet the rise time requirements for even 100KHz.
Now the software libraries have been improved since version 4.121 quite a lot, so probably clock the bus faster than they did in V4.121.....

[Fusillade]

[PCM programmer]

[Fusillade]

[Ttelmah]

Just to make a comment about the resistor value.

Standard mode I2C, has a specified maximum rise time of 1uSec.
The rise time is specified as 0.847RC (where R is the pull up, and C the bus capacitance). Turning this round gives:

C=Trise/(0.847*R)

So solving for 1uSec and R=47K, gives:

C=25.1E-12

25pF.

So the absolute maximum bus capacitance that can be used with 47K, is 25pF total, to actually be 'in spec' for 100K I2C. Now when you consider that most chips will have something like 5pF pin capacitance, this doesn't give a lot of allowable track capacitance before the bus will go out of spec. Probably about 75mm maximum trace length.

Now software I2C, does not mind out of spec rise times generally. Your original code was using software I2C. Historically in 4.121, the maximum I2C clock rate generated, was Fosc/64. So with your 4MHz clock, 62500bps. This would have been the rate you were generating. The V5 I2C library has been slightly optimised and gives Fosc/52, so would be defaulting to 77000bps. Hence dropping the rate to (say) SLOW=60000 would be necessary to meet your timings.

[Fusillade]