SC18IM704 Data Faults

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SC18IM704 Data Faults

1,852 Views
NFCbrick
Contributor II

Hello,

On an #SC18IM704  Eval Board UM11664, I had observed some, for me unexpected behaviour.

For Payload of 1 Byte, I observed the transmission of 2 Bytes. And no - I am not referring to the transmission of the slave adress.

When sending certain values in payload, there is something that looks like CRC send happening which is neither expected, nor described in the manual.

What did I try:

1) I am using Clock 01d4, (4,06kHz) - But the described glitch also appeared with the default clock setting.

2) I am sending 1 Byte and observe data and clock on the scope, there is no target hardware connected to the i2c lines.

3) For all tested byte contents (see attachments for 0x00 and 0xB5 for reference) there happens exactly what I wanted and which is according to the datasheet.

4) For these two suspicous values 0xA5 and 0xC5 The "bit excess" is generated.

I read

0xA580 for payload write 0xA5 (for input via UART of 53 cc 01 a5 50)

and

0xC507 for payload write 0xC5 (for input via UART of 53 cc 01 c5 50)

 

Where does this come from?

Best regards, NFCbrick

Labels (1)
Tags (3)
0 Kudos
4 Replies

1,789 Views
NFCbrick
Contributor II

Hi,

As described, the only option different from default settings are I2CClkH, I2CClkL.

I assume the device comes with some configuration allowing it to function as a "UART to I2C-bus bridge"...
Do I need to alter any Registers to ensure that?

I am sorry I cannot relate to how chapter 4.4 would help me in any way - there were no obvious reasons to check "Register read", "Register Write", "GPIO as input", "GPIO as output" ... to describe the problem I had with "Write N bytes to target device". The command I claimed is not even mentioned in this chapter.

The reported issue covers 7.1.1 "Write N bytes to target device".

And yes, I have used
52 07 50 and 52 08 50 to verify my clock settings. Which, as yet mentioned are seemingly not causal for the missbehaviour. I could reset them to 13 and 00 and the problem still occurs.

Did you try to establish the scenario I have described, David?

Have a good Day,
kind regards

0 Kudos

407 Views
diazmarin09
NXP TechSupport
NXP TechSupport

Hello Stefan,

Please accept my apologies for the delayed response.

I have already performed some tests with the SC18IM704-EVB evaluation board and difference I2C slaves and everything is correct. You can perform your tests with the on-board EEPROM.

diazmarin09_0-1711480926852.png

(Reading 1 byte from the on-board EEPROM)

In this case, I have some questions for you:

  1. Could you please share the exact data frame that you are sending to the SC18IM704 device?
  2. What is the I2C slave device that you are using?
  3. Am I misunderstanding your question?
0 Kudos

1,795 Views
diazmarin09
NXP TechSupport
NXP TechSupport

Hello NFCbrick,

I hope all is great with you. Thank you for using the NXP communities.

I do recommend referring to the Sample control sequences from UART host (chapter 4.4) mentioned on the document below.

UM11664 - SC18IM704-EVB evaluation board

Could you please confirm that you have the correct device configuration?

Regards,

David

0 Kudos

472 Views
NFCbrick
Contributor II

Would you please refer to my question, I gave many details yet. @diazmarin09 

kr

0 Kudos