I2C Slave problem from >5.085

[monsun]

I have a project which is working in the field on dozens of devices for 8 months. Project has uart communication, i2c master on SSP1 and i2c slave on SSP2 and is using CCS RTOS. It was first built on 5.085.
PIC24FV16KM202

After few months i needed to make other version of the same devices and I upgraded my compiler to 5.092 and started a slightly modified firmware on new compiler.

First I thought that i've made some bug changing program, but after two days of solving problem i found the problem is in compiler. I have looked through the listing and didn't find anything very different between those versions, but version from .092 is behaving strange as if it had some trouble keeping up with the i2c master clock.

I don't want now to put a code because it is too big to show it.
I'm using interrupt routine which is very similar to ex_slave
I'm using 4Mhz internal RC and master I2C is using 100khz.

Anyone have any problems with I2C on >5.085

[temtronic]

I have to ask, since you had working code with 5.085, WHY did you upgrade the compiler ?
Unless you needed some new features or functions ??

Hopefully someone that has those versions will respond soon.

I would go back to 5.085 and use it in the meantime.

[monsun]

I've upgraded it because i it is slightly new project and i saw a lot of improvements in optimization and others and because of earlier problems with moving from .074 i just wanted to use fresh, newer and "better".

I've never had so many problems with CCS when i was working on version 4 as on 5.

And of course i move back to 5.085 with this one.

[PCM programmer]

Here are the listed changes to i2c functions in PCD since vs. 5.085:

5.092 i2c_transfer() functions fixed when using stream identifiers with functions in PCD.
5.090 Improved error detection for when an incorrect stream identifier is passed to I2C functions
5.089 Updated i2c_read() function so for 1 param it figures out if it is stream or ACK.
5.089 Added a new i2c_write_slave() function so slaves can push data to the master in an ISR without waiting.
5.088 Fixed a PCD issue causing i2c_write() to hang when operating as Master and sending the I2C global address.
5.086 Fixed an issue with PCD H/W i2c_transfer() function slave ACK.

http://www.ccsinfo.com/devices.php?page=versioninfo

[Ttelmah]

Very difficult to know, but for example, if the stream identifier is not
being quite correctly used, some of the listed fixes might then actually cause
problems.
I'm using I2C slave on a 24FJ64GB002, talking to a 33EP512GM304
master, and both run correctly with the current compiler. Master is using
DMA, and slave is based directly in the CCS ex_slave.c
You chip doesn't have any errata for the I2C (one thought was that
an erratum fix had got 'lost' in the function re-writes).
I'd be looking very carefully at the code and verifying that the stream
name is genuinely used everywhere. I've seen one oddity with a
previous 'automatic' stream selection not working. This could be your
problem.

[monsun]

About stream identifiers I've had this problem earlier and i check my code for it, stream identifiers are used everywhere. I also don't use i2c transfer functions, everything is made in classic methods with i2c_write, read and i also use ack functions attributes everywhere.

[Ttelmah]

Start by narrowing down the search through the listings. All I2C functions
only, and compare the actual code generated.
Do you anywhere use i2c_read(STREAM), without explicitly declaring
the ACK/NACK?. I'm wondering about this change:

5.089 Updated i2c_read() function so for 1 param it figures out if it is stream or ACK.

If you do use I2C_read like this try explicitly declaring the ACK/NACK
everywhere this is used.

[monsun]

I've made some more test today.
1) I'm using everywhere Stream identifiers and ACK/NCK attribute.
so that's not this
i'm using internal RC oscillator earlier i was using declaration like this:

[temtronic]

Sadly, this post shows what can happen when an 'update' occurs.
CCS fixes a problem but that creates another one 'somewhere' else, which may be hidden or goes unnoticed until some combination of 'things' happen. Then that gets 'fixed' but, oops, another 2 problems pop up.

I understand some new features are nice, making programming easier ( like complicated peripheral setups) but just HOW can anyone thoroughly test 100% of a compiler with 100s of functions for 1000s of PICs ? The task is impossible, hence a 'bug' or two or three...

Updating anything can have problems, so 'if it ain't broke, does what you NEED, don't upgrade'.

[gaugeguy]

internal=3.6864MHz is not a valid setting for the PIC24FV16KM202.

This has an 8MHz and 500kHz internal oscillators so you can get:
32MHz, 16MHz, 8MHz, 4MHz, 2MHz, 1MHz, 500kHz, 250kHz, on down to 1.95kHz.

If you had things working using 3.6864MHz setting then it was not really running at that speed it was hiding some timing mistakes in your code.

[Ttelmah]

Yes.
Lets think about what having the clock value declared 'low' would do.
It would imply that all delays would actually be slightly longer than
they are asked to be. So if you have delay_ms(10), you would actually
get a delay of 10.85mSec.
It does firmly suggest that there is at least one timing problem in the code.
Possibly the old compiler was merrily accepting this invalid clock value,
while the new one is not (and is automatically using 4MHz). This change
is causing the timing issue to become visible.....

[monsun]

OK, i've thought i made mistake with this clock and that's the reason i changed it to 4Mhz, because i assumed it is 4Mhz. I made now test at 8Mhz and it looks everything ok. And the question is why on real 4Mhz i2c is not working as fast as on fake 3.8Mhz:)

I've RTOS and I2C is on interrupt

[gaugeguy]

There are timing problems in code not shown. Most likely something is taking too long and when running at a higher frequency allows it time to complete without interfering with other tasks.

[monsun]

I've moved

[temtronic]

this...