- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would check the signals using a logic analyzer.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Signals seem to be good, cannot see the voltage levels.
Now scope with BCP.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Of course I have nothing with a CY7* chip on it. A lot of PSoC 5LP stuff though....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh, maybe you easier to buy)).
https://www.saleae.com/
saleae logic analyzer / 24M sampling 8-channel
Logic Analyzer Oscilloscope 16x Digital/Analog Inputs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!