PSoC42xx and 47xx I2C slave configuration problem

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

cross mob
Yves
Level 2
Level 2
10 replies posted 5 replies posted 5 sign-ins

HI all,

I have been developing a small board and application for CY8C4245 using I2C bus.

unfortunately, due to the current supply chain problems, we had to select a 4745 for our design, so we can release the product much sooner.

I configured the I2C exactly the same way as the 4245 in PSoC creator, but I have problems with the communication with 4745.

I have looked at everything I could but can't figure out why it doesn't work the same way... 😞

Am I missing something?

0 Likes
1 Solution

Hi,

the 8051 timings are respecting the I2C specification, so I thought it would be ok. I didn't check the timing spec for SCB blocks though.

I have now replaced the I2C with EZI2C and the communication works just fine, so I don't think it's just the SCB version, but maybe the I2C slave driver specific to SCB V2?

View solution in original post

0 Likes
19 Replies
MiNe_85951
Level 7
Level 7
Distributor - TED (Japan)
50 likes received 500 replies posted 50 solutions authored

Hi,

 

I think the I2C of PSoC4200 and PSoC4700S are the same SCB component and there is no difference.

However, the PSoC4200 is a device that has been released for a long time, and the PSoC4700S is a relatively new device.

Is the version of the SCB component used in the PSoC4200 different from the version of the SCB component used in the PSoC4700S this time?

I can only think that the problem is due to a software description error, the external pull-up resistor of the I2C bus, or the capacitance of the I2C bus.

 

Regards,

0 Likes

Hi MaMi,

thank you for your answer 🙂

the SCB component is the same for both families, I configured it exactly the same way, the I2C clock also has the same value. the code is also doing the same things for initialization and address setting by reading an ADC input (this works fine).

the I2C pull-ups seem to be the right value, 4.7K for 100Kbps, but maybe I could try to tweak that a bit and see what happens...

but why wouldn't the I2C work with 4745 and work with 4245 then?

kind regards

0 Likes

Hello.

Can you provide the exact and full PSoC part number for the 4245 and the 4745.

The 4745 has Smart I/O instead of UDB in 4245.  I don't use Smart I/O PSoC's.  I wonder if this is causing the issue?

When you say it doesn't work, please provide details of what dosen't work?
Do you not see the clock?
Do you not see the data pin toggling?
Does it not receive data?
Is 4745 configured as a Master or as a Slave?
Is the  'other' I2C device using 5Volt signals or 3.3V signals?
Do you know if any of the code is running?  Have you tried blinking an LED?

Details will help us to help you.

0 Likes

Hi,

thanks for your message.

the I2C seems to partly work, the frames are not what they should be, except from time to time, even though my PSoC is set as slave. the 4745FNI-S412, as well as the 4745 on the CY8CKIT-148, behave the same with I2C, they answer to the address & read/write byte (always a write in this design) sent by the master, then a few bytes are seen on the data line but they are not what is expected. however, those "wrong frames" are always the same (they contain the same bytes).

the I2C clock seems ok.

I see the pins toggling, my logic analyzer reads the frames, but still need to make proper oscilloscope measurements to see if the edges are good.

the PSoC does receive data, even sometimes the right frame (I can see with my logic analyzer that it is only good from time to time).

the voltage is 5V.

the code runs well and I can run it in debug, I have an ADC input to determine the I2C address, that works well, and an SPI communication which works fine too, and also 2 PWM outputs which work just fine... I don't get it.

kind regards

0 Likes

Hello.

Thanks for providing details.  This helps.

So in summary, PSoC 4745 is programmed as a 5Volt i2C slave.  The PSoC is receiving i2C data, but it sends incorrect replies to the i2C master.  And sometimes the PSoC replies with the correct data.

Okay then.  Sounds like it's all software related.

So, what changed in the code between 4245 image and 4745 image?

There is a code example in Creator for an i2C slave (not dependent on which PSoC 4 is used).  Take a look at that example to see if it might shed some light on why PSoC is either not receiving the expected data, or not sending the expected data.

I'd suggest you review this excellent i2C code example from Motoo.  It deals with several communication ports.  However, the i2C example is for a Master.
https://community.infineon.com/t5/Code-Examples/MCU-Tester-a-Swiss-Army-Knife-for-PSoC-CY8CKIT-044-v...

Question: does i2C logic analyzer show i2C master is sending correct data?

0 Likes

Hello,

it is not exactly the behaviour, let me try to explain better (hopefully):

my PSoC is slave and only receives write messages from the master, never read messages. so it only needs to acknowledge the received bytes. which is managed by the automatically generated APIs.

my PSoC ACKs for the right device address, but then the data bytes sent are meaningless, even though they are always the same. (Except when the expected ones are received, which happens rarely and randomly).

the code I wrote to manage I2C is similar in both projects. based on the code given as I2C slave example in the documentation you get for SCB / I2C in PSoC creator.

anyway, even if my code is wrong, I should normally see the right frames sent by the master, but it's mostly not the case. So I would guess for a configuration mistake.

However, I use the same SCB block for both projects, with the same settings, and the clocks are similar.

I will check this code example, thank you.

it is when using the logic analyzer that I see most of the frames are not containing the right data, and they are not even of the right length (wrong number of bytes, there are only 3 instead of 6). even though according to the analyzer there are proper start / ack / stop conditions detected.

0 Likes

Hi.

Well, I'm thoroughly confused now.

This is beginning to sound like the master is at fault and not the slave.  If the master is supposed to send 6 bytes, but only sends 3, then there's a problem with i2C master.

What you are using for i2C master?
Did this software change?

0 Likes

Hi.

to be exact, I am replacing an obsolete display driver chip with a PSoC on an old design using 8051 type controller, hence the 5V. this 8051 is the I2C master.

This design works perfectly with 6 I2C slaves on the bus, and also when I replace one of the I2C slaves with the 4245 CY8CKIT-042. but not with 4745 CY8CKIT-148 or my little pcb.

There is no way I can update the code from the 8051 but maybe I could find the source and try to understand if it comes from it or not.

but this software has not changed in years and we never had any issue with it.

0 Likes
Yves
Level 2
Level 2
10 replies posted 5 replies posted 5 sign-ins

watching with a proper scope now, it seems my logic analyzer doesn't tell me the truth...

... to be continued...

0 Likes
Yves
Level 2
Level 2
10 replies posted 5 replies posted 5 sign-ins

it seems the master doesn't manage to set the clock high for the 9th clock edge which is for the ACK/NACK, for the address write, then maybe my device gets confused when receiving the following edges. or, can the PSoC somehow force SCL down after receiving the first byte? I am using I2C slave, not EZI2C so not stretching should be possible...?

0 Likes

Hello.

From what you observed, it sounds like 4745 is clock stretching.  It's an indication the 4745 is not ready for a transaction.  It also indicates 4745 validates an i2C address match.

Is 4745 put into sleep mode?  The master i2C can wake up 4745 via i2C and this is one of the reasons for 4745 clock stretching.

I wonder if i2C master supports clock stretching?  A normal 8051 uP doesn't have an i2C block.  So, it's either bit-bashing an i2C function, or the 8051 is a more modern device with i2C support (in which case, it should support clock stretching).

The 4745 should have an i2C control register to enable/disable clock stretching.  You could try flipping this bit and test the result.

0 Likes

Hi,

yes, I checked the master's code and it seems fine. So it really seems the 4745 is doing something wrong like pulling the SCL down at the ACK moment.

My plan now is to check and compare the drivers for 4745 & 4245.

the stretching option is only for the EZI2C, but who knows, there could be a bug somewhere in the automatically generated code... let's see

Also, I don't understand why the slave would do clock stretching because on my CY8KIT-148 with 4745, I have only the I2C running now.

again, thank you for your help!

0 Likes

Hi.

Another option is to try testing 4745 with i2C Bridge Control app that comes with Creator installation.

Let us know what you discover.  A bit of a mystery at this moment.

0 Likes

I've compared the drivers, they are similar in code, but the I2C_1_CY_SCBIP_V0 is defined for 4245 and I2C_1_CY_SCBIP_V2 for 4745, so the SCB block is not managed exactly the same way for both chips...

Didn't help me much so far 😞

0 Likes
Yves
Level 2
Level 2
10 replies posted 5 replies posted 5 sign-ins

Yves_0-1642674446408.jpeg

Here's a scope screenshot to show the 9th clock edge is not there when the address byte should be ACKed

0 Likes
Yves
Level 2
Level 2
10 replies posted 5 replies posted 5 sign-ins

So I think I will write my own drivers, old school style, which is a shame when using PSoC but it is what it is.

thanks a lot for the help 🙂

kind regards

0 Likes

Hi.

You've done some good detective work.

You should start a new thread with the scope capture showing 9th clock missing.  Someone from Cypress should respond.  They'll likely ask for a sample project that creates the problem so that they can duplicate it at their end.

Good luck with your project.

0 Likes

Hello.

Another thought...
I wonder if 8051 SDA output timing meets 4745 SCB I2C_1_CY_SCBIP_V2 setup and hold timing spec (relative to SCL)?

You'd need to zoom in on the scope image and take careful measurements.  Then , compare against the timing spec in I2C_1_CY_SCBIP_V2 (found in component datasheet).

MaMi could very well have been right when he suggested the SCB component version might be at fault.

0 Likes

Hi,

the 8051 timings are respecting the I2C specification, so I thought it would be ok. I didn't check the timing spec for SCB blocks though.

I have now replaced the I2C with EZI2C and the communication works just fine, so I don't think it's just the SCB version, but maybe the I2C slave driver specific to SCB V2?

0 Likes