ATSHA204 with Wemos D1 Mini

[Anticimex]

@elcaron the personalizer relies on the driver. So it is the driver you should focus on. There is nothing in the personalizer that configure how to communicate with the atsha except for the pin to use.

[elcaron]

Ok, this is madness. With the default SecurityPersonalizer sketch, it fails pretty reproducably.
If I add another Serial.print statement at the end of the setup funktion (I initially printed "Looping", but copying "Serial.println(F("Personalization is now complete."));" also works), it works pretty reliably.

In the oscilloscope I see reproducable timing of the wakeup pulse and the first following pulse in the second version, but in the first, original version, the two measurements had different timings. Qualitatively, in the nonworking version, the first pulse after the wakup is longer than the following one, in the working version, it has the same length.

Again, the only difference is commenting and uncommenting the additional Serial.print statement. ATSHA is on D2.

If nobody has an idea how o reliably prevent this, I conclude that I cannot use the ESP8266 with the ATSHA, since I might run into the issue any time again under uncleared circumstances.

[Anticimex]

@elcaron I have no such hardware so I am not sure what the reason can be, but it looks like timing is different on that device. The atsha driver should not need adapting since it works fine on samd devices which also have different timing, but perhaps the corresponding low level i/o drivers work differently on esp. Perhaps @Yveaux has an idea.

[Anticimex]

@elcaron if the only thing causing problem is after the setup or wake up, please consider adding something in the driver for esp targets so that this delay is ensured. If it works for all the other things, the i/o timing is fine, the esp is probably just too quick in starting to communicate after a wakeup. This should be handled by the driver. Just be aware that there are two versions of the driver. One in the sketch folder that contains all the needed logic to do personalization, and a different optimized one under drivers which is used by the MySensors library. The same fix is probably needed in both, but the fix should only apply to esp targets.

[Yveaux]

@anticimex said in ATSHA204 with Wemos D1 Mini:

Perhaps @Yveaux has an idea.

Sorry, not really. I don't have an ESP/ATSHA setup, so I'm unable to replay.

@elcaron Did you verify timing on your oscilloscope w.r.t. the ATSHA datasheet?

[Anticimex]

@elcaron if you can confirm the i/o timing, I have a strong suspicion that the issue here is the time after a wakeup command and the next command. The esp is probably too quick to attempt it, so the driver need a extra delay after wakeup to ensure this does not happen. I can implement something, but I am going to have to rely on you to test and verify the fix.
So it would be helpful if you

1. Measured the delay in the working and non working code.
2. Checked the datasheet if there is a statement on wakeup delay
3. Personalized a gw and a node (the node could use sw signing) so we can test both variants of the driver.

I will give you some suggestions for adapting the driver for the tests. We can take it in a chat instead of littering the thread with experiments.

[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.