ATSHA204 with Wemos D1 Mini

[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

[Anticimex]

@zboblamont I don't think 'atomic' in programming language means what you think it means based on your reaction ;)

[Anticimex]

@yveaux @elcaron I think a plausible explanation for the problem could be that the esp wifi interrupts, when unchecked, can break the bit banging protocol in the atsha driver and cause timing problems. If it helps to turn off the interrupts in the personalizer (which will not need wifi so that is a valid fix) the driver might need some critical sections to ensure timing is ensured with respect to the atsha during "normal" operation.

[elcaron]

Haven't managed to do more tests today. Was trying to get a simple sensor + Gateway2MQTT config running, but the gateway just didn't receive any messages, despite the fact that Radiohead can use my RFM69HW hardware with at least 2.4GHz Wifi range. But let's not highjack my own thread :) I'll start a new one next weekend when I'll also try to run the personalizer without Wifi.

[elcaron]

Found some time again. Could not solve the issue with disabling Wifi. Further, I got a bunch of ESP32, which should have a dedicated core for Wifi, and I still cannot get it working.

I have recorded the traces with a logic analyzer, compared to a Pro Mini and after the initial pulse, the timings seem to be vastly different. I only have sigrok pulseview available, and I find it hard do do any further analysis with it (including exporting it into any sensible format to import it to e.g. MATLAB ...)
Here are the Sigrok session files for a Wemos LOLIN32 and an Arduino Pro Mini, if anybody is interested.

I have also scoped the waveforms, they are pretty fine in both cases. The Pro Mini is on the same breadboard and powered by the LOLIN, they both have the same code fresh from Github (only change is ATSHA pin to pin 4) and the only thing I did between the two recordings is plug a jumper cable from pin 4 of one device to pin 4 for the other.

[elcaron]

Over two years have passed and I have started another try, with no more success than last time. There seems to be a Sparkfun library that very close to the one in the SecurityPersonalizer script, but doesn't run with the ESP32 at all, despite being marked so in PlatformIO. ow are these related and could there be other version that are better adjusted to the ESP32?
Has anyone ever made any progress on this in the past 2 years?

[Anticimex]

@elcaron I do not have the necessary hardware (or the time) I am afraid. I hope the community can help.