I2C I2C_MasterWriteBuf function help

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
DaBr_1233126
Level 4
Level 4
10 likes given 5 likes given First like received

I have 2 PSoC 4 devices that I want to talk to each other via I2C.

   

One of these is connected to an NewHaven 128x32 bit LCD.  I can use the Bridge Control Panel to communicate with the LCD Slave with no problem.

   

ex:  W 10 00 00 00 00 00 00 32 38 54 53 53 4f 50 00 p

   

Displays    '28TSSOP'   on the top line of the LCD as I expected.

   

However when I use the attached project, the following code seems to be working, but nothing appears on the LCD.

   

<code>

   

    i2cstat = I2CLCD_I2CMasterWriteBuf(0x10, (uint8 *)i2c_buf, BUFFER_SIZE, I2CLCD_I2C_MODE_COMPLETE_XFER);
    if (i2cstat == I2CLCD_I2C_MSTR_NO_ERROR )     //  I2CM_MSTR_NO_ERROR
    {
        PWR12V_Write( ~PWR12V_Read() );
    }
</code>

   

PWR12V is connected to an LED and it toggles, which tells me there isn't an error from the write buffer command.

   

Any help is appreciated.  I've been banging my head on this for 2 days now...

   

Dan

0 Likes
16 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I only can see that in the BCP example are 6 leading 0x00 after the I2C address and in your program I can find only 5 leading variables

   

        sprintf(NEW_BUF, "Changing Power State");

   

this is not conform to your defined packet size of 22

   


        SendCommand( 0x01, 0x02, 0x10, 0x00, 0x00, NEW_BUF);

   

and that looks quite different to your working example.

   

Why don't you send the array '00 00 00 00 00 00 32 38 54 53 53 4f 50 00' (transform to hex data yourself) via I2C to verify that the interface of your board works or that it needs some corrections (as pull up resistors)

   

 

   

Bob

0 Likes
DaBr_1233126
Level 4
Level 4
10 likes given 5 likes given First like received

BCP requires a start address which is the value right after the device address.  If it was needed as part of the array, I would just process my command 2 which would clear the lcd, that isn't happening either.

   

Per your suggestion, I tried :

   

    char i2ctest[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x32, 0x38, 0x54, 0x53, 0x53, 0x4f, 0x50, 0x00};
    i2cstat = I2CLCD_I2CMasterWriteBuf(0x10, (uint8 *)i2ctest, sizeof(i2ctest), I2CLCD_I2C_MODE_COMPLETE_XFER);

   

And got the same results.  ie none

   

Pullups are installed.  If I change to the other I2C port the led never changes state, due to no pullups there.

   

Is there anything else I might be missing?

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I would check the signals using a logic analyzer.

   

 

   

Bob

0 Likes
DaBr_1233126
Level 4
Level 4
10 likes given 5 likes given First like received

I don't have one of those.  I connected a cheap oscope to the pins and get the attached waveform.  I don't know enough to be able to understand it though.  From my understanding it looks like it is way to short to be a full transfer.  (looks like 2 bytes?)

   

   

   

0 Likes
DaBr_1233126
Level 4
Level 4
10 likes given 5 likes given First like received

Sorry for two images there.  One shows when I edit and the other does not.   Anyhow, the red is the clock line and yellow is data. 

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Signals seem to be good, cannot see the voltage levels.

   

Now scope with BCP.

   

 

   

Bob

0 Likes
DaBr_1233126
Level 4
Level 4
10 likes given 5 likes given First like received

Highs on the scope were 3.298V so as I am pulling up to 3.3V I figured that was good.

   

How do you scope using BCP?  I've never seen anything in the lower window unless I had it actively sending something.  (Like echos...)

   

If you have a link to a tutorial I'd love to have it.

   

And thanks Bob for your help!  It is so helpful to have a second view of something!

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

How do you scope using BCP? Connect the scope inputs to your LCD (do that in both cases to eliminate wire errors). BCP will drive the lines or PSoC will. Use the same I2C lines for all tests.

   

 

   

Bob

0 Likes
DaBr_1233126
Level 4
Level 4
10 likes given 5 likes given First like received

This is actually how I have been doing things all along.  Pullup resisters are on the LCD board and I have a second connector in parrellel that has the KitProgs I2C lines going to it.  What I don't know is how to monitor what is going on that isn't generated by the KitProg with the KitProg and BCP.

   

As a side note, I noticed that the I2C pins from the KitProg do have pullups on them.

   

So do you know how to use the KitProg and BCP as an I2C sniffer?  If not, I will have to find another tool to do that.  Suggestions welcome!

0 Likes
EvPa_264126
Level 7
Level 7
500 replies posted 250 replies posted 100 likes received

If you have a board with  CY7C68013A on-board.
eg (CY8CKIT-003/014/030/050)
You can replace the ROM and get a logic analyzer.
My version alterations described   here  (russian).

0 Likes
DaBr_1233126
Level 4
Level 4
10 likes given 5 likes given First like received

Of course I have nothing with a CY7* chip on it.  A lot of  PSoC 5LP stuff though....

0 Likes
DaBr_1233126
Level 4
Level 4
10 likes given 5 likes given First like received

OK.  I found an old Bus Pirate.  After 3 hours of searching, I figured out how to use it and was able to see the exchanges.

   

Using BCP to send a message to invert part of the screen I see the following:

   

[0x20+0x00+0x04+0x00+0x00+0x02+0x80+]

   

But when I use the code from PSoC I am seeing:

   

[0x20+0x40-]

   

0x20 is the address and write bit.  Same on both, so everything is good there.

   

0x00 is the buffer location to start write.  PSoC is trying to start writing at location 0x40 which does not exist and would be locked out, so the NACK.  How do I set where the next write goes in the API?  The start location isn't being incremented.  So what am I missing?

0 Likes
EvPa_264126
Level 7
Level 7
500 replies posted 250 replies posted 100 likes received

I do not have this device, so I changed the address on 0x1E
I ran your program and connected analyzer.
Hopefully it to you somehow help.

   

0 Likes
DaBr_1233126
Level 4
Level 4
10 likes given 5 likes given First like received

Thanks for the image Pavloven!  Unfortunantly, all i am seeing is that garbage is being sent out.  After the Address should be a 0x01 0x02 0x10, but I am not seeing that anywhere in the stream.

   

Thanks also for the suggestion for an analyzer.  I did order one today.  Just got the shipped notification a few minutes ago.  So in a week, I should have my own.  Yea!

   

I think I will try rewriting this to send it byte by byte instead of using the buffer approach.  I just have to remember that buffer[0] has to be written last for the Slave to process it correctly.  (It waits for change from 0xFF to start processing...)

   

Thanks for all the help!!!

0 Likes
DaBr_1233126
Level 4
Level 4
10 likes given 5 likes given First like received

OK  Incase someone else sees this thread later on, I am posting the code I ended up using to transmit the buffer in a way the EZI2C can understand.

   

<code>
    commStatus = I2CLCD_I2CMasterSendStart(LCD_I2C_ADDRESS, I2C_WRITE);
    commStatus += I2CLCD_I2CMasterWriteByte(0);             // Register to start write at.
    //  Send the buffer out!
    for( i = 0; i < sizeof(i2c_buf); i++ )  commStatus += I2CLCD_I2CMasterWriteByte( i2c_buf );
 
    commStatus += I2CLCD_I2CMasterSendStop();
</code>

   

I hope this is helpful to others in the future!

0 Likes