ATSHA204 with Wemos D1 Mini

[elcaron]

I have little time this afternoon, but I'll try to find more tomorrow. For documentation purposes, timing counted in ms from the triggering falling edge of the wake pulse:

Working, reproducible
0 falling
0.0725 rising
3.1638 falling
3.1694 rising
3.1790 falling
3.1846 rising

Non working, not exactly reproducible, only in the fact that the middle pulse is longer, instead of equal to all following pulses.
0 falling
0.0685 rising
3.1557 falling
3.1653 rising
3.1748 falling
3.1804 rising

What is strange is that my change in the code is the LAST line of the setup function. It happens AFTER the "Personalization complete" line. I don't see how it should change anything, without any serious compiler voodoo.
I have commented and uncommented the additional line at least 10 times, with multiple subsequent resets each, and there is no doubt it's that effect.

[Anticimex]

@elcaron compiler woodo is always a possibility, it is the first delay difference i think is the key here. We just need to define a way of ensuring proper delay, and I think it will be more stable.

[Anticimex]

@elcaron may i ask what library version you are using? "Personalization complete" is not printed by the current personalizer. Could you please do a test with the beta/development branch, or the 2.2.0 release?

[elcaron]

I have been using 2.1.1, just updated to 2.2.0 with the Arduino library manager.

It seems I am still getting

+------------------------------------------------------------------------------------+
|                                  Execution result                                  |
+------------------------------------------------------------------------------------+
| FAILURE (last ATSHA204A return code: 0xE7)                                         |
+------------------------------------------------------------------------------------+

with the unaltered (only hardcoded const int sha204Pin = D2;) sketch. Have to check with oscilloscope this evening., will report back.

[elcaron]

Correcxtion: My bad, seems to work. Still really weird and looks random. How did code that is not called before everything should be finished influence the result?

[Anticimex]

@elcaron I see. That code indicate that the chip is not responding as expected. We can experiment with various delays but best is to have an oscilloscope to get a working baseline. If you have a AVR node or similar with an ATSHA, you could run the same sketch on that and grab the timings, so we are sure to compare apples with apples.

[Anticimex]

@elcaron oh, ok. Not sure about why it affected the result to modify the last lines in the old sketch. But the compiler might do some sketch things when optimizing the code.
What is it that appear random now, with 2.2.0?

[elcaron]

2.2.0 looks fine by now, but the hardware in general still behaves randomly until it is at least halfway clear why this very strange behavior in 2.1.1 occures.
Anyway, its just the gateway, not lots of nodes. I'll go ahead with this, Can still change it if more issues come up.

Thanks for the great work on this.

[Anticimex]

@elcaron Ok. Just let me know if you notice any erratic behavior with esp and atsha204a using the current (or future) versions of the library. The driver should take care of any timing requirements of the device, but you never know what the compiler might be up to...

[elcaron]

Spoke too soon.

I tried to generate AES and HMAC keys, but I think it it cannot hold the connection reliably:

+------------------------------------------------------------------------------------+
|                           MySensors security personalizer                          |
+------------------------------------------------------------------------------------+

+------------------------------------------------------------------------------------+
|                               Configuration settings                               |
+------------------------------------------------------------------------------------+
| * ATSHA204A based personalization                                                  |
| * Will generate HMAC key using ATSHA204A                                           |
+------------------------------------------------------------------------------------+

+------------------------------------------------------------------------------------+
|                           Hardware security peripherals                            |
+--------------+--------------+--------------+------------------------------+--------+
| Device       | Status       | Revision     | Serial number                | Locked |
+--------------+--------------+--------------+------------------------------+--------+
| ESP8266      | DETECTED     | N/A          | A6EE1400EF401800AA           | N/A    |
+--------------+--------------+--------------+------------------------------+--------+
| ATSHA204A    | NOT DETECTED | N/A          | N/A                          | N/A    |
+--------------+--------------+--------------+------------------------------+--------+

+------------------------------------------------------------------------------------+
|                                   Key generation                                   |
+--------+--------+------------------------------------------------------------------+
| Key ID | Status | Key                                                              |
+--------+--------+------------------------------------------------------------------+
| HMAC   | FAILED | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF |
+--------+--------+------------------------------------------------------------------+

+------------------------------------------------------------------------------------+
|                                  Key copy section                                  |
+------------------------------------------------------------------------------------+
#define MY_HMAC_KEY 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF
+------------------------------------------------------------------------------------+

+------------------------------------------------------------------------------------+
|                                       EEPROM                                       |
+--------+--------+------------------------------------------------------------------+
| Key ID | Status | Key                                                              |
+--------+--------+------------------------------------------------------------------+
| HMAC   | RESET  | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF |
| AES    | RESET  | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF                                 |
| SERIAL | N/A    | Device unique serial, not stored in EEPROM                       |
+--------+--------+------------------------------------------------------------------+

+------------------------------------------------------------------------------------+
|                      This nodes whitelist entry on other nodes                     |
+------------------------------------------------------------------------------------+
{.nodeId = <ID of this node>,.serial = {0x01,0x23,0xD7,0xA6,0xFB,0x0C,0x55,0x23,0xEE}}
+------------------------------------------------------------------------------------+


+------------------------------------------------------------------------------------+
|                                  Execution result                                  |
+------------------------------------------------------------------------------------+
| SUCCESS                                                                            |
+------------------------------------------------------------------------------------+

I see more data transmitted here than when it fails immediately. It is also different from when I just pull the cable:

+------------------------------------------------------------------------------------+
|                           MySensors security personalizer                          |
+------------------------------------------------------------------------------------+

+------------------------------------------------------------------------------------+
|                               Configuration settings                               |
+------------------------------------------------------------------------------------+
| * ATSHA204A based personalization                                                  |
| * Will generate HMAC key using ATSHA204A                                           |
+------------------------------------------------------------------------------------+

+------------------------------------------------------------------------------------+
|                           Hardware security peripherals                            |
+--------------+--------------+--------------+------------------------------+--------+
| Device       | Status       | Revision     | Serial number                | Locked |
+--------------+--------------+--------------+------------------------------+--------+
| ESP8266      | DETECTED     | N/A          | A6EE1400EF401800AA           | N/A    |
+--------------+--------------+--------------+------------------------------+--------+
| ATSHA204A    | NOT DETECTED | N/A          | N/A                          | N/A    |
+--------------+--------------+--------------+------------------------------+--------+


+------------------------------------------------------------------------------------+
|                                  Execution result                                  |
+------------------------------------------------------------------------------------+
| FAILURE (last ATSHA204A return code: 0xE7)                                         |
+------------------------------------------------------------------------------------+

For a while I was able to also read the serial number of the ATSHA, but I cannot get there anymore. Electrically, everything seems fine, flanks have rise and fall times of <5ns.

After the setup, my ESP tries to connect to an SSID which I don't have anymore every second. This is despite the fact that I ran the ClearEepromConfig sketch. Maybe that one also is not ESP8266 compatible

[Anticimex]

@elcaron in both cases it fails to detect your atsha device so something is not healthy with the driver and your esp board. I am afraid I have no clue what it might be. The driver is designed to ensure device timings are kept. I also double checked that it ensures proper delay after wakeup. So either the esp port timer is lying or there is something else that is dodgy.
I am sorry to say I have no statistics on atsha users so I don't know if anyone else have been using it successfully with esp or if you are the first to ever attempt it.

[elcaron]

I'll try another D1 Mini tomorrow. I have already tried it before when it just failed with 2.1.1, but this time, I'll investigate further.

I think the ESP looses sync at some point. in 2.1.1 immediately, when I first tested with 2.2.0 between detection of ATSHA and key generation, now between wakeup acknowledgement and ATHSHA detection (serial and such)

[Anticimex]

@elcaron it might be that something takes too long time and the atsha watchdog kicks in. But I find that highly unlikely as the esp is far more powerful than a atmega328p. I appreciate that you dig more at some point. I'll gladly assist any way I can.

[elcaron]

Some more findings:

• On my Wemos D1 Mini Pro, I can reliably (3 alternating uploads, multiple resets each) read the serial number when I flash with 160MHz setting in the IDE, but not with 80MHz. Key generation fails with both frequencies. I think if looses sync later, but eventually, it does.
• I could reproduce this with 2 Wemos D1 Mini from different batches. One of those fresh from that back, the other two where used for MySensors tests before and try to connect to my old Wifi every second after the sketch.

ESP8266 board code now fresh from Github. Again, I had similar issues with the ESP and the single wire interface of the DHT22. The ESP is a single core that runs wifi functions in the background. It just might not be up to the task of keeping these timings accurate.
I ordered an ESP32 module last week, that should have one core dedicated to the sketch. Until then, I will use soft signing on the gateway. If anyone would like something tests, I can try, though.

[Anticimex]

@elcaron thanks for testing. So it might be that the wifi thread cause the atsha watchdog to bark, which nukes any ongoing session. I can have a look if adding some kicking of it or sleeping the atsha between accesses might help. Is there any way of disabling the wifi in the sketch? Or make it execute in a critical section so that personalization is done undisturbed?

[elcaron]

@anticimex WDT resets are usually indicated on the console. They happend a lot after the 2.1.1 sketch, but I haven't seen them after.
I was more optimistic about the Wifi thing, before I tested a module that wasn't contaminated with an old MySensors config and didn't obviously try to connect.
Are you using interrupts in the driver? If not, maybe disable them? As soon as I find time, I will try with calling

  WiFi.disconnect();
  WiFi.mode(WIFI_OFF);
  WiFi.forceSleepBegin();

At the beginning of the setup function.

That doesnt yield an immediate solution though, because we will need signing to work with Wifi. But it could give a hint.

[Anticimex]

@elcaron I am talking about the internal watchdog in the atsha. It ensures not too long idle activity is present between chained commands. Wifi is not needed for personalization and during normal operation, operations to the atsha should be pretty much atomic. We need to test that of course, but personalization needs to work first.

[zboblamont]

@anticimex "...operations to the atsha should be pretty much atomic" :scream:

[Yveaux]

@anticimex said in ATSHA204 with Wemos D1 Mini:

internal watchdog in the atsha

According to the datasheet Twatchdog has a minimum value of 0.7sec and 1.3sec typical. That's ages in embedded-land, even for an esp that gets rescheduled by the wifi stack.

[Anticimex]

@yveaux I know, but something on esp is not healthy with the atsha since 80 and 160 MHz operations differ