Get response from AT88SC0104CA (I2C)

Projects Networking, Protocols, and Devices
1

I have a Arduino UNO as a master and a AT88SC0104CA CryptoMemory as a slave. The communication between the devices are via I2C.

The following slave recquires a command for writing/reading, and there is a sample taken from a logic analyzer of how it should work:

Sem tĂ­tulo
Sem tĂ­tulo1000Ă—226 10 KB

As you can see, the clock changes after a command set (4 bytes). Since changing the clock is not possible while a device is operating, the last byte might be a response from the slave (right?). This particular command set is for setting the zone.
I'm having issues to receive data like this from the slave device.

Receiving data on Arduino recquires a requestFrom(). But this function "sends more data" to the slave as you can see:

Sem tĂ­tulo(1)
Sem tĂ­tulo(1)1344Ă—207 12.6 KB

Code used:

  Wire.beginTransmission(0x5A);
  Wire.write(0x03);
  Wire.write(0x00);
  Wire.write(0x00);
  delayMicroseconds(10);
  Wire.endTransmission();
  Wire.requestFrom(0x5A, 1);
  Wire.read();

How could I possibly get the same result as the first image? Mainly how to get data without requestFrom(). (still learning more from the datasheet but stuck at this point)

(tried to be more direct and specific here, but my knowledge on Embedded Systems are not the best, nor my English.)

2

I2C has 9 clocks and I only see 8, so that is not I2C.

3

Then what could it be?
Datasheet says it works with a synchronous (I2C) and asynchronous ISO 7816-3, is that the case?

4

That must be what you are seeing but I'm not familiar with that protocol.

1 Like
5

The datasheet says:
The synchronous mode is the default mode after power up. So it should be in I2C mode unless you are starting it in async mode.

7

Start-up sequence suggests that it is not a I2C initialization:

image
image438Ă—192 864 Bytes

But I don't think it might be the asynchronous initialization neither.

image
image549Ă—191 9.85 KB

Does that mean it is working on "default" (I2C)?

8

You need to look at all the signals shown in figure 7-2 in order to determine which mode it's starting up in.
Are you supplying it with a CLK during power-up and holding RST low?

9

Not sure about the RST, it should be on the NC ports but apparently they have no contact on this particular project.
I'm just assuming things by looking at the CLK.

Weird to say, but all the sample communication that "works" seems to have a few differences.. It's like looking at the wrong datasheet but it is actually the right one. Literal nonsense.

10

Then it should power up in I2C mode.
Are you sure your logic analyser is working correctly

11

Pretty sure it is, didn't change the ports for the second read, only devices.
Even so, there is the difference in the number of clocks and both are supposed to be I2C I guess.

12

The first device is the actual one who makes contact with the chip.
Second one (Arduino) is to replicate and read other parts.

13

Are you sure it's a AT88SC0104CA because according to the datasheet, it requires 9 clocks.

14

It is sending the Set User Zone to 1 command. The 0x5A is actually a 0xB4 when looking at all 8 bits.
0xB4 0x03 0x01 0x00
This command does not require a response, so I think that those other 8 slow clocks is a reset sequence from the Master. It may actually work OK with only 8 clocks so it's not truly I2C compliant.

15

I see. When I write to other address like 0x58, it actually gives a 0xB0.
The problem comes when I try to read a user zone. The only way I can do it is by sending 0xB2. Turns out that sending it only works if I directly write 0xB2 or start a transmission with the address 0x59.
Even tough, there is still a need to call a command set to read, then the device answer.
But as mentioned

And after some research, with Wire.h library it is technically impossible.

16

Started to use Microchip Studio.
Not sure if using the Arduino UNO will still be good, anyways I contacted Microchip to get some "example code" mentioned on application notes.
This one does not send a new data before reading, but the reading process is really odd.
Soon I will receive more orientantion and post final conclusions here.

17

The response of CryptoMemory will cause contention with the host on a standard TWI/I2C bus. Typically CryptoMemory cannot be used on a standard TWI bus but requires a modified TWI protocol to account for it.

After a while, I got some response and well, that explains a lot.

Basically writing data wasn't an actual problem for typical I2C bus. But that's a different story for reading/receiving data from the CryptoMemory.

18

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.