ATSHA204 with Wemos D1 Mini

[elcaron]

Now, this is probably a stupid question, since there are PCBs and all around, so it seems to work, but how are the experiences on the ESP8266/Wemos D1 Mini, especially with the ATSHA204?
I made an RFM69HCW/ATSHA204A breakout, it works with an Arduino Pro Mini, but I am completely unsuccessful with my Wemos D1 Mini that was supposed to be the gateway.
With the ESP8266, I saw one successful run from the SecurityPersonalizer, but could never reproduce it.

• I soldered the jumper cables to the pins to rule out breadboard issues (with the Pro Mini, solderless breadboard works)
• The ATSHA does have a pullup and a close-by bypass cap with 100nF
• I hardcoded the pin in the personalizer sketch. (This works with the Pro Mini )

I am a little bit out of ideas. The error, "Failed to wake device. Response: E7", stays the same when I change to a different pin.
The only other lib I found was the Sparkfun lib, which only compiles after one change of uint8_t->uint32_t in the header file, but also does not give successful results.
I DO remember, though, that I also have mixed results with the DHT22, so it seems the timing required for one-wire devices on the ESP8266 is a bit rubbish.

Any experiences?

And if not: is there even a security advantage in an ATSHA on the gateway, which is stored safe in my attic, or would software signing on the comparably fast ESP be just as good?

[Anticimex]

@elcaron you might want to check that you stay within timing requirements on the single wire bus since it is bit banged and might be off if timers are not running as expected.
And yes, for a gw, it is typically less critical to have readout protection of the keys.

[elcaron]

I'll hook up my oscilloscope next week end. I hoped to get some response if people have the ATSHA running with the ESP8266 and if it was in any way tricky. If it is, it maybe should be documented somewhere to save other people some time, given that the ESP is e.g. part of the main wiring documentation and probably the choice for a gateway.
I haven't changed anything but the pin definition in the Personalizer sketch, so if there is a problem in that regard, it is a general one (and even if people have it running out of luck, they may not have a stable config).

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

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

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