search

helium / ecc608-linux-rs

A linux rust library for the i2c ecc508 and ecc608 family of crypto chips
9 stars 13 forks source link

Incorrect wake command sent to chip prior to read / write command #1

Closed PeterHeckel-TEK closed 2 years ago

PeterHeckel-TEK commented 3 years ago

Using the ATECC608A chip and using this library in conjunction with gateway-mfr-rs, all read / write attempts were met with timeout errors indicating that the communication was failing.

Analyzing the i2c SDA line shows that the wake command that the ECC608 chip requires was not correct. The wake command was using the assigned address of the ECC chip instead of the 0 address that is specified.

The root of the issue seems to come from the send_wake function in ecc.rs using the send_buf method which defaults the address to be the given ECC i2c address.

The send_sleep function may also suffer from the same issue.

madninja commented 3 years ago

Using the ATECC608A chip and using this library in conjunction with gateway-mfr-rs, all read / write attempts were met with timeout errors indicating that the communication was failing.

Analyzing the i2c SDA line shows that the wake command that the ECC608 chip requires was not correct. The wake command was using the assigned address of the ECC chip instead of the 0 address that is specified.

The root of the issue seems to come from the send_wake function in ecc.rs using the send_buf method which defaults the address to be the given ECC i2c address.

The send_sleep function may also suffer from the same issue.

Interesting, so the spec status address 0 should be used for sleep/wake? The code appears to work fine with the 608B so I'm wondering what the difference is

PeterHeckel-TEK commented 3 years ago

According to the datasheet here under the AC Parameters I/O Interfaces, a wake command is specified as a low data line for at least 60 us, then a high data line for at least 1500 us. So depending on the i2c address used, that may have been triggered implicitly when the first address was sent as a wake command.

The debugging guide that I was reading indicated that sending an address 0 is the easiest way to wake the chip, but I imagine you could hard code the data lines to go high and low for those specified durations instead if required.

There seems to be no difference between the ECC608A and B versions.

madninja commented 3 years ago

So did you try changing it to use address 0 and did it behave better? Note that linux does get in the way a bit of the lower level spec details

PeterHeckel-TEK commented 3 years ago

Yes I hacked together a change and instead of calling send_buf[&0] directly in the send_wake function, I directly used the i2c.i2c_transfer method to send a 0 address and 0 data byte.

This change allowed me to communicate with the chip with no issue

madninja commented 3 years ago

Could you submit a PR?

PeterHeckel-TEK commented 3 years ago

Yup, sorry for the delay, been quite busy.

madninja commented 2 years ago

Fixed by #3