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 problem with sensor PAJ7620U2 [Solved]
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Jun 16, 2020 9:43 am     Reply with quote

Before trying anything else, just try reducing the I2C bus rate.
The PIC code will default to the 400K. It's possible the Arduino is defaulting
slower. Now 2.2K, is not a high speed value for 3.3V, and with the
extra propagation delays introduced by the buffering, it may just be
that the slew rate limits are being exceeded.
(Given it has 2K2 resistors on the 3.3v side as well).
So, something like:
#use i2c(master, fast=200000, sda=PIN_B0, scl=PIN_B1, SMBUS)
ddevices



Joined: 15 Jun 2020
Posts: 13

View user's profile Send private message

PostPosted: Tue Jun 16, 2020 10:02 am     Reply with quote

I injected your #use statement but no luck, same results. I am firmly convinced there is no problem with the I2C bus, it must be failing on enable because some other register is not correct. I just don't understand why it works with Arduino.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Jun 16, 2020 12:56 pm     Reply with quote

Post the bank select code. That this needed to be sent twice, may give a
clue what is going on.
ddevices



Joined: 15 Jun 2020
Posts: 13

View user's profile Send private message

PostPosted: Tue Jun 16, 2020 1:15 pm     Reply with quote

Code:
void paj7620SelectBank(int8 bank) {
    int8 ack;
    int8 data[2];
    data[0] = 0xEF;
    data[1] = bank;
    ack = i2c_transfer_out(PAJ7620_write,data,2);
    if(ack==1)
      printf("Bank Failure %d\r",ack);
    else
      printf("Bank Good!\r");
}

It is normal to send this twice at start. First time it will be seen as a 'wake up' command - from datasheet "Write slave ID or I2C read command to process I2C wake-up." When I do this twice at start of program the serial debug output will say 'Bank Failure' followed by 'Bank Good'. First command wakes up chip but does not process the command.
ddevices



Joined: 15 Jun 2020
Posts: 13

View user's profile Send private message

PostPosted: Tue Jun 16, 2020 3:40 pm     Reply with quote

I changed the code section where I initialize the registers:
Code:
    for (i = 0; i < 219; i++) {   
        data[0] = initRegisterArray[i][0];
        data[1] = initRegisterArray[i][1];
        printf("%u %x %x\r",i,data[0],data[1]);
        ack = i2c_transfer_out(PAJ7620_write,data,2);
        if(ack==1) printf("Init Failure %u\r",i);   
        delay_ms(10);
        paj7620ReadReg(data[0], 1, &val);
        printf("feedback %x %x\r",data[0],val);
      }

This provides feedback of each value into each register. It did indeed verify that each register was correctly written to and contains the right parameter. It also proved the I2C bus is working. At this point I am truly stumped.
ddevices



Joined: 15 Jun 2020
Posts: 13

View user's profile Send private message

PostPosted: Tue Jun 16, 2020 4:41 pm     Reply with quote

In thinking about it, I have an obvious question. Why does the PIC stop? If the PAJ is 'not ready' to run then when I send 0x72 0x01 to enable it, it should just have a NACK on the I2C line. And it does, I have measured it with scope and meter both SDA and SCL are high (5V). It should return failure of that attempt to write. But instead with that one register it locks up the PIC. There are a total of four lines connecting the gesture board to the PIC board, GND, +5V, SDA, and SCL. When it locks up GND is 0V, +5V is +5V, SDA and SCL are high - why would that stop the PIC? This makes no sense. I ran program without gesture board attached to PIC board and I get feedback of all write failures, but PIC never locks up.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Jun 17, 2020 1:55 am     Reply with quote

Normally I2C would only hang, if SCL is held low. This is saying the slave
needs to delay the I2C transaction, so the PIC holds.

To hold when high, implies something else is happening. Is it possible
there is something like EMI actually hanging the PIC?. How good is the
line suppression next to the PIC. I'm wondering if the 'spike' when the
PAJ sensor actually switches on, is actually hanging the PIC. It draws under
3mA, so it seems unlikely, but the 'timing' of the hang is suspicious.

However, big question. What compiler version do you have?.
I think you are hitting an I2C errata on the PIC. Errata 38:
Quote:

38. Module: MSSP
If the application firmware is expecting to receive
valid data, in either SPI Slave or Master mode, the
firmware must read from the SSPBUF register
before writing the next byte to transmit to SSPBUF.
If the firmware does not read from SSPBUF, the
BF bit (SSPSTAT<0>) can still be set from the previous
transaction. If the BF bit is set, the incoming
data byte is blocked from transferring from the
SSPSR Shift register to the SSPBUF register. If
the firmware then reads from SSPBUF, the data
read will not match the data most recently received
on the SDI pin.

If the transfers get blocked from reading the buffer data, result 'hang'...
This was fixed on the compiler a while ago, but may have either reappeared
or you have a compiler that predates the fix.

This can be fixed in your code. Wherever you use 'I2C_write' to send a
value, re-code like:
Code:

byte new_i2c_write(byte data)
{
     byte dummy;
     if (i2c_poll()) //test if there is a byte in the input buffer
         dummy=i2c_read(); //if so, read before the write
     dummy=i2c_write(data);
     return dummy;
}

//Used like...
     i2c_start();
     new_i2c_write(PAJ7620_write);     
     new_i2c_write(0x72);
     new_i2c_write(0x01);
     i2c_stop(); 


Use this for _every_ I2C_write instruction.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Jun 17, 2020 4:44 am     Reply with quote

Ttelmah wrote:

Is it possible there is something like EMI actually hanging the PIC ?

He should set all unused i/o pins to be outputs, and set them low.

He is using #fast_io() on ports A and B:
Quote:

set_tris_a( 0b11111111 ) ;
#use fast_io( A )
set_tris_b( 0b11111111 ) ;
#use fast_io( B )
set_tris_c( 0b10111110 ) ;

He currently has most pins set to be inputs, with probably many floating inputs.
ddevices



Joined: 15 Jun 2020
Posts: 13

View user's profile Send private message

PostPosted: Wed Jun 17, 2020 5:30 am     Reply with quote

Ttelmah and PCM Programmer, I think you are on to something. I will try your suggestions and I'm thinking there is a power problem as well. Carefully hidden in datasheet it says the PAJ spikes to 800ma, that is a lot for a board that runs off USB. My compiler is V5.093c and I do have pull ups on most of my inputs (which I use for other things). I can't test today but will do so tomorrow and let you know results.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Jun 17, 2020 6:48 am     Reply with quote

Ouch!...
800mA, is very likely to cause problems. What reservoir capacitor have you
got on the supply rail?. What is it's ESR rating?. (You realise this is more
than a USB port is rated to supply...).
The load is actually specified 2A max. However 'normal operating conditions'
have it as 430mA max. 500uSec max duty cycle<5%. Now this would
correspond to 100Hz. So calculating a reservoir capacitor to bring ripple
below perhaps 45mV, gives a capacitor of 0.5mF (yes, half a _milli_ farad).
This needs to have good HF performance, so something like a tantalum
470uF capacitor.
So something like the ones listed here:
https://www.mouser.com/Passive-Components/Capacitors/Tantalum-Capacitors/Tantalum-Capacitors-Solid-SMD/_/N-75hr4?P=1z0wrk5Z1yx4avt
You'd really need some form of inrush current limiter on this.


I'm solidly thinking this is where the problem actually is...
ddevices



Joined: 15 Jun 2020
Posts: 13

View user's profile Send private message

PostPosted: Thu Jun 18, 2020 6:33 am     Reply with quote

That was it! All I had was 150uf cap but it did the trick. There was nothing wrong with code or I2C bus, the spike from the sensor turning on was locking up the PIC. Thanks to everyone for their help, and Ttelmah's guidance.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Jun 18, 2020 6:53 am     Reply with quote

Good!.
You'll probably have perhaps 100mV spike, but that is small enough that
it obviously works!.
Lesson is that anything with momentary spike currents must have
enough reservoir capacitance close to it, to keep the spikes on the
power rails to acceptable limits. Things like motors and solenoids are
the worst, followed by possibly things like RF circuits, and then things
like this with a high current LED spike. Just how much momentary power
they are pulsing through the LED is quite surprising!...

I must admit the module you have 'surprised' me, by having proper
level shifters for the I2C. Many times better than most designs, which is
why I at first thought this was likely to be the problem.

Hope progress goes as it should now. Smile
temtronic



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

View user's profile Send private message

PostPosted: Thu Jun 18, 2020 7:13 am     Reply with quote

sigh.... I never thought of it being a power supply issue but.... it does make sense...
being an old guy I tend to use high capacity PSUs. Smallest I use is rated for 10 amps and linear..... kinda stuck on 'old skool' stuff.....
sure happy it's working !!!

now onto the next head scratchin problem !!
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 Previous  1, 2
Page 2 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