ATSHA204 with Wemos D1 Mini

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