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

I2C Slave problem from >5.085
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
monsun



Joined: 17 Jan 2012
Posts: 17

View user's profile Send private message

I2C Slave problem from >5.085
PostPosted: Mon Mar 23, 2020 6:37 am     Reply with quote

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



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

View user's profile Send private message

PostPosted: Mon Mar 23, 2020 7:00 am     Reply with quote

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



Joined: 17 Jan 2012
Posts: 17

View user's profile Send private message

PostPosted: Mon Mar 23, 2020 7:13 am     Reply with quote

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



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Mar 23, 2020 7:24 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Mar 23, 2020 8:43 am     Reply with quote

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



Joined: 17 Jan 2012
Posts: 17

View user's profile Send private message

PostPosted: Mon Mar 23, 2020 11:02 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Mar 24, 2020 2:56 am     Reply with quote

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



Joined: 17 Jan 2012
Posts: 17

View user's profile Send private message

PostPosted: Tue Mar 24, 2020 5:58 am     Reply with quote

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:
Code:
#use delay(internal=3.6864MHz,restart_wdt)
#use i2c(MASTER, FORCE_HW, I2C1, FAST=100000, RESTART_WDT, stream=I2C_PORT1)
#use i2c(SLAVE, FORCE_HW, I2C2, RESTART_WDT, address=0xCC, stream=I2C_PORT2)
#use rs232(baud=57600, uart2, stream="PC", ERRORS)

but i had some problems with uart so i decide to change baudrate and internal clock to
Code:
#use delay(internal=4MHz,restart_wdt)
#use i2c(MASTER, FORCE_HW, I2C1, FAST=100000, RESTART_WDT, stream=I2C_PORT1)
#use i2c(SLAVE, FORCE_HW, I2C2, RESTART_WDT, address=0xCC, stream=I2C_PORT2)
#use rs232(baud=38400, uart2, stream="PC", ERRORS, BRGH1OK)


and changing internal RC to 4MHz starts causing problems with i2c even on 5.085 very similar to those when i change compiler to 5.092
temtronic



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

View user's profile Send private message

PostPosted: Tue Mar 24, 2020 6:02 am     Reply with quote

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



Joined: 05 Apr 2011
Posts: 286

View user's profile Send private message

PostPosted: Tue Mar 24, 2020 6:59 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Mar 24, 2020 7:32 am     Reply with quote

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



Joined: 17 Jan 2012
Posts: 17

View user's profile Send private message

PostPosted: Tue Mar 24, 2020 8:04 am     Reply with quote

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
Code:
#use rtos(timer=1,minor_cycle=10ms)

#task (rate=10ms, max=2ms)
void uart_receiver();
#task (rate=10ms, max=5ms)
void adc_reader();
#task (rate=100ms, max=6ms)
void result_updater();
#task (rate=10ms, max=100us)
void adc_rate();

#INT_SSP2
void i2c_isr(){
   UNSIGNED int8 incoming,state;
   state=i2c_isr_state(I2C_PORT2);
   
   IF(state<=0x80)
   {//Master is sending data
      IF(state==0x80)
         incoming=i2c_read(I2C_PORT2,2);
      ELSE
         incoming=i2c_read(I2C_PORT2,1);

      IF(state==1){//First received byte is local register address
         local_register_address=incoming;
      }
      ELSE IF(state>=2 && state!=0x80)
      {
         i2c_buffer[local_register_address]=incoming;
         local_register_address++;
      }
   }

   IF(state>=0x80){//Master is requesting data
      i2c_write(I2C_PORT2,i2c_buffer[local_register_address]);
      local_register_address++;
   }
   
   if(i2c_buffer[16]){
      i2c_init(I2C_PORT2,0);
      rtos_terminate();
   }
}
gaugeguy



Joined: 05 Apr 2011
Posts: 286

View user's profile Send private message

PostPosted: Tue Mar 24, 2020 8:10 am     Reply with quote

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



Joined: 17 Jan 2012
Posts: 17

View user's profile Send private message

PostPosted: Tue Mar 24, 2020 8:15 am     Reply with quote

I've moved
Code:
void i2c_isr(){
//!   UNSIGNED int8 incoming,state;
   state=i2c_isr_state(I2C_PORT2);

those variables declaration out of interrupt to global area and now it looks good in first tests.

I need as lowest current consumption as it is possible so i'm working on an edge here.
temtronic



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

View user's profile Send private message

PostPosted: Tue Mar 24, 2020 8:52 am     Reply with quote

this...
Quote:
I need as lowest current consumption as it is possible

implies a battery powered device although you have a serial stream labeled 'PC' which you could get power from ?

IF battery powered AND the PIC goes to 'sleep', you need to ensure the PIC is running at operating speed BEFORE trying to do any 'timed' operations, like I2C, RS232, RTOS.

While I don't use that PIC, I know that PICs do require some time to 'get organized'. That may not be causing your I2C problem (which seems solved) but.... could cause other 'random' problems.

Just something to be aware of....

Jay
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 1, 2  Next
Page 1 of 2

 
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