Riot: Wrong I2C address for ATECC (cryptoauthlib)

[Citrullin]

Description

I connected an ATECC806A to a nRF52832 and created a new board for it. I used the cryptoauthlib integration in RIOT.
Unfortunately, it doesn't work. After some debugging with a logicanalyzer, I think I found the cause.
The default value of ATCA_I2C_ADDR is 0xC0. When you look in the physical result on the I2C bus, it results in 0xC1 and the crypto IC is not sending an ACK.
But, when you change the value to something else, for example 0xC9, the physical result is also 0xC9. The wakeup on address 0x00 seems to work fine, since the IC sends some ACKs on other dataframes and the pulse on SDA is > 1ms. The cryptoauthlib does a lot of bit shifting etc. So, I guess there is an issue at some point.

Steps to reproduce the issue

I try to push my code. Not sure, if this is reproducible on the samr30-xpro with the ATECC608A.

Expected results

No error on initialization

Actual results

2020-05-01 16:05:00,459 # [auto_init_atca] error initializing cryptoauth device #0

Versions

Operating System Environment
----------------------------
         Operating System: "Ubuntu" "19.10 (Eoan Ermine)"
                   Kernel: Linux 5.3.0-22-generic x86_64 x86_64
             System shell: /usr/bin/dash (probably dash)
             make's shell: /usr/bin/dash (probably dash)

Installed compiler toolchains
-----------------------------
               native gcc: gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
        arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
                  avr-gcc: missing
         mips-mti-elf-gcc: missing
               msp430-gcc: missing
     riscv-none-embed-gcc: missing
     xtensa-esp32-elf-gcc: xtensa-esp32-elf-gcc (crosstool-NG esp-2019r2) 8.2.0
   xtensa-esp8266-elf-gcc: missing
                    clang: missing

Installed compiler libs
-----------------------
     arm-none-eabi-newlib: "3.1.0"
      mips-mti-elf-newlib: missing
  riscv-none-embed-newlib: missing
  xtensa-esp32-elf-newlib: "3.0.0"
xtensa-esp8266-elf-newlib: missing
                 avr-libc: missing (missing)

Installed development tools
---------------------------
                   ccache: ccache version 3.7.3
                    cmake: cmake version 3.13.4
                 cppcheck: missing
                  doxygen: missing
                      git: git version 2.25.1
                     make: GNU Make 4.2.1
                  openocd: Open On-Chip Debugger 0.10.0+dev-01000-gdb23c13d (2020-01-10-01:06)
                   python: Python 2.7.17rc1
                  python2: Python 2.7.17rc1
                  python3: Python 3.7.5rc1
                   flake8: error: /usr/bin/python3: No module named flake8
               coccinelle: missing

Maybe @Einhornhool or @jue89 can help with this.

[PeterKietzmann]

The ATECC508A datasheet (Sec. 2.2 EEPROM Configuration Zone, Table 2-5 Byte 16 ) clearly states the default I2C address 0xC0 which can be "modified from default by writing a new value into the configuration zone". The ATECC608A is designed to be fully compatible with the ATECC508A with a couple of additions. Regarding I2C, that is "Programmable I 2 C address after data (secret) zone lock". Some ideas:

• Connect to an other platform. Maybe there is something wrong in the i2c driver on that platform.
• Try an I2C scanner to find the correct I2C address (there is a shell command in RIOT that I just found).
• There is a "cryptoauth" shell command as well, which reads and dumps the configuration zone (depends on working communication obviously).
• Which device are you actually using? CryptoAuth Xplained Pro shield might need some jumpering.

@Einhornhool other ideas?

[Citrullin]

The ATECC508A datasheet (Sec. 2.2 EEPROM Configuration Zone, Table 2-5 Byte 16 ) clearly states the default I2C address 0xC0 which can be "modified from default by writing a new value into the configuration zone". The ATECC608A is designed to be fully compatible with the ATECC508A with a couple of additions. Regarding I2C, that is "Programmable I 2 C address after data (secret) zone lock". Some ideas:

* Connect to an other platform. Maybe there is something wrong in the i2c driver on that platform.

* Try an I2C scanner to find the correct I2C address (there is a shell command in RIOT that I just found).

* There is a "cryptoauth" shell command as well, which reads and dumps the configuration zone (depends on working communication obviously).

* Which device are you actually using? CryptoAuth Xplained Pro shield might need some jumpering.

@Einhornhool other ideas?

I also thought about the platform. The nRF52 uses this dynamic pin configurations as I remember. So, it is possible to have some kind of bug in there.
What is the shell command to find the I2C address?
I just use the ATECC608A with the I2C on the nRF52. I just soldered it and connected it on a breakout board.

[PeterKietzmann]

I also thought about the platform

And did you go further than thinking about it :-)? I have used the ATECC5/608A with a samr21-xpro and a nucleo-f410rb so far, worked like charm.

What is the shell command to find the I2C address?

Haven't used it so far. Check out the PR that introduced it #11240. Otherwise, there are many I2C address scanners around that can be run on different analyzers, just google a bit.

I just soldered it and connected it on a breakout board.

So you don't have an "official" breakout board available for reference? What are the I2C pins on the nRF52832? Did you use the development board from Nordic? Did you consider pull-ups on the I2C lines, does the Nordic have "strong-enough" ones?

@Einhornhool can you try this configuration?

[Citrullin]

I also thought about the platform

And did you go further than thinking about it :-)? I have used the ATECC5/608A with a samr21-xpro and a nucleo-f410rb so far, worked like charm.

Just tried it with a blackpill. Unfortantly, I don't have another board supported by RIOT.
Similar behavior. Unfortunately, I only get some kind of response with I2C_SPEED_FAST. I2C_SPEED_NORMAL results in no response at all.
The

So you don't have an "official" breakout board available for reference? What are the I2C pins on the nRF52832? Did you use the development board from Nordic? Did you consider pull-ups on the I2C lines, does the Nordic have "strong-enough" ones?

No, I don't have one. P0.27 SCL, P0.26 SDA. No official Nordic DK, just this module with a breakout board.
Yes, I considered using pull-ups on 3.3V and 5V with 1.2 kΩ resistors like mentioned in the docs.
Unfortunately, with pull-ups the IC is not responding. I guess the IC is not able to pull the lines down. I will try it with higher resistance. I checked it with resistor and without resistor. The level without pull ups is ~ 2.95V - 3.1V. While with pull-ups 3.3V - 3.4V.
I uploaded the data of the logic analyzer. (Saleae)
setup_crypto_nrf52_I2C_SPEED_FAST.logicdata = I2C bus with speed I2C_SPEED_FAST and no pull-ups.
setup_crypto_nrf52_I2C_SPEED_NORMAL.logicdata = I2C bus with speed I2C_SPEED_NORMAL and no pull-ups.

[PeterKietzmann]

I only get some kind of response with I2C_SPEED_FAST. I2C_SPEED_NORMAL results in no response at all.

This is expected. #13412 will improve this.

When you look in the physical result on the I2C bus, it results in 0xC1 and the crypto IC is not sending an ACK.

This is just an interpretation of the tool. We have 7-bit addressing in place and the 8th bit indicates read/write (read=1 in this case).

Did you try the I2C address scanner?

[Citrullin]

I only get some kind of response with I2C_SPEED_FAST. I2C_SPEED_NORMAL results in no response at all.

This is expected. #13412 will improve this.

When you look in the physical result on the I2C bus, it results in 0xC1 and the crypto IC is not sending an ACK.

This is just an interpretation of the tool. We have 7-bit addressing in place and the 8th bit indicates read/write (read=1 in this case).

Did you try the I2C address scanner?

Okay, this is more confusing then. ATCA_I2C_ADDR has the value of 0xC0 which does not fit in the 7-bit addressing.
Yes, I tried it.

2020-05-04 15:25:30,976 # Scanning I2C device 0...
2020-05-04 15:25:30,982 # addr not ack'ed = "-", addr ack'ed = "X", addr reserved = "R", error = "E"
2020-05-04 15:25:30,986 #      0 1 2 3 4 5 6 7 8 9 a b c d e f
2020-05-04 15:25:30,989 # 0x00 R R R R R R R R R R R R R R - -
2020-05-04 15:25:30,993 # 0x10 - - - - - - - - - - - - - - - -
2020-05-04 15:25:30,996 # 0x20 - - - - - - - - - - - - - - - -
2020-05-04 15:25:31,000 # 0x30 - - - - - - - - - - - - - - - -
2020-05-04 15:25:31,004 # 0x40 - - - - - - - - - - - - - - - -
2020-05-04 15:25:31,008 # 0x50 - - - - - - - - - - - - - - - -
2020-05-04 15:25:31,011 # 0x60 - - - - - - - - - - - - - - - -
2020-05-04 15:25:31,015 # 0x70 - - - - - - - - R R R R R R R R

It's the other way around. I2C_SPEED_FAST has some response, while I2C_SPEED_NORMAL doesn't. The pulse for fast is 0.12 ms and for normal 9 ms. So, it should be fine in both cases, I guess. But the i2c scan results in both cases the same result, while it looks completely different on the logic analyzer. I am confused.

[PeterKietzmann]

I would suggest to get an official development shield first, to make sure your problems are not related to the breakout board. We will give it a try tomorrow with the cryptoauth-shield and a nRF52 DK.

[Citrullin]

I would suggest to get an official development shield first, to make sure your problems are not related to the breakout board. We will give it a try tomorrow with the cryptoauth-shield and a nRF52 DK.

I also found another breakout board. The address there is also different. Interesting. I thought 0xC0 is the default one. I would like to get it running with this breakout board, because if I mess the configuration up, I need another one. Which is ~ 0.8 Euro for one mess up, while the official breakout board costs ~ 9.00 Euro.

[PeterKietzmann]

It says 0x60 which reflects the upper 7 bits of 0xC0. Personally, I would still recommend to buy one "established" kit to play around with and to figure out if you're dealing with hardware or software issues. However, we should get one step further tomorrow after we managed (or not) to run the cryptoauth shield with the Nordic board.

[Citrullin]

It's quite simple. I got the 1-wire version....
ATECC608A-SSHCZ-B...

[PeterKietzmann]

Just set it up before reading this. tests/pkg_cryptoauthlib_compare_sha256/ works on nrf52dk + ATECC608A (on cryptoauth-xplained B).

[Citrullin]

@PeterKietzmann Works like a charm. Connected the breakout board and it works fine. Also got the official one. So, wasted 10 bucks, but I guess it is fine :D Thanks for the help though. :)