💬 Ikea Molgan Hack

[Anticimex]

@LastSamurai ok, and what about memory? Do you have a percentage of how much ram there is left after programming?

[Anticimex]

@LastSamurai I find it slightly disturbing that you say 115200 baudrate does not work. That would suggest the clock is not running as it should. I can run 115200 just fine on my Nano (16MHz) and Pro mini (8Mhz).
The personalizer on the development branch uses the baudrate set by the MyConfig.h setting (MY_BAUD_RATE) so you define it using that flag (as you found out).

[Yveaux]

@Anticimex the Molgan Hack uses the internal oscillator, not an external crystal like the nano and pro mini.
The internal oscillator is less accurate, hence the lower baud rate.

[Anticimex]

@Yveaux ah, ok. That explains that then. But to my knowledge there is no timing dependency for software signing, except the signing timeout. But I think there is a debug message if that fires. If not, perhaps @LastSamurai could try to increase the timeout (currently at 5000 ms).

[LastSamurai]

Ok for the molgan sketch the arduino IDE spits this out:

• list item22.602 Bytes (73%) of memory
• list itemglobal variables 56% of dynamic memory

How do you change the timeout? Quick googling only turned up requests to make it configurable...

[Anticimex]

@LastSamurai it is configurable, and clearly visible where all signing configuration parameters are located in MyConfig.h. Look for MY_VERIFICATION_TIMEOUT_MS.

[LastSamurai]

Thanks, haven't really looked in that file since the upgrade to mysensors 2. Doing it all in the sketches now. I'll test it and get back to you.

[Anticimex]

@LastSamurai I do not think the timeout is the issue here, but worth a try anyway. The memory usage is in the red zone if over 70% I'd say so I suspect the hmac key gets corrupted by a stack that grows into the heap. You can test that by adding a debug print in the soft signing backend that dumps your hmac key before it is set. Assuming you run the latest stable release you'd want to place the print just before this line. You can copy this line and replace _signing_hmac with _signing_hmac_key. Also change the HMAC text to HMAC KEY to tell them apart (and don't post your printed key here ;))
This to verify that the key used is the key you personalized and that it has not been corrupted.

[LastSamurai]

@Anticimex So adding this around the line 325 should do the trick, right?

// Feed "message" to HMAC calculator
	DEBUG_SIGNING_PRINTBUF(F("HMAC key debug: "), _signing_hmac_key, 32);
	_signing_sha256.initHmac(_signing_hmac_key,32); // Set the key to use

The output of that is

HMAC key debug: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

which is definitly not my HMAC key!

PS Changing the timeout did not change this.

[Anticimex]

@LastSamurai alright, so there are now three options:

1. Your device is not properly personalized
2. Your key has been overwritten in eeprom by some other part of your sketch during runtime
3. Your key has been erased by stack growth (unlikely since it very much look like eeprom reset value)

You can test the various scenarios by moving your newly added print to various places in the backend. For instance, adding it just after the value is fetched from eeprom in the init function of the backend would tell you if the value is bad in eeprom or is erased in ram at a later stage.

[LastSamurai]

The HMAC key seems to already have been FFFFF.... when read from EPROM. While testing some more I somehow seem to have bricked the atmega328 though :( I just soldered a new board and will to some more testing tomorrow.

[Anticimex]

@LastSamurai alright. Perhaps the molgan sketch does some eeprom operations which inadvertently erases the key. You could try to read the key from eeprom early in the sketch after it was personalized just to confirm it had the key at some point at least.

[LastSamurai]

Hah success! Until now I was programming the chip directly via an USBasp (ignoring any bootloaders). I guess thats how I "bricked" the other chip (accidentally burning fuses that indicate an external clock...).

Today I burned a bootloader (with the right fuses) to the new board and uploaded the securityPersonalizer and the molgan sketch via serial... and everything is working! It takes some (re)tries to get the signing up and running but after ~2 seconds the molgan board showed up in the gateway log. Now I'll only have to connect the new board to the molgan pcb and hope that everything still works.

I still don't know why it wasn't working before though. I have some other chips that I programmed via ISP and they work well with signing too...

[Anticimex]

@LastSamurai nice. My best bet is that you somehow erased your eeprom after personalizing it. But anyway, nice that you are fully up and running now :)

[Jan Gatzke]

@LastSamurai How exactly did you flash it? I am using an USBasp, too. As it seems I have bricked 2 atmega328p and one Arduino Pro mini already. :dancer:
This is what I did:
"C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avrdude.exe" -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -B 40 -c usbasp -p m328p -b 11520 -P usb -V -v -U efuse:w:0xFE:m -U hfuse:w:0xDA:m -U lfuse:w:0xE2:m

"C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avrdude.exe" -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -c usbasp -p m328p -b 115200 -P usb -V -U flash:w:ATmegaBOOT_168_atmega328_pro_8MHz.hex

After this I am not able to flash sketches via the Arduino IDE. Any ideas?

[Jan Gatzke]

Never mind, it's working now. I soldered a completely new pcb and this time it runs without problems. I still have no idea, why it did now work on first try. But I guess it has something to do with the fact, that I used hot air and solder paste for the first time. :)

Edit: I have assembled all the stuff and the node is kind of working. It presents itself to the gateway perfectly. What does not work is the motion sensor. The pin is always high. When I pull it down manually and release it again, the node sends its message.
I have removed the light sensor and R17. I have replaced R11 with a 1k resistor because that was the smallest one I had. Could this be a problem?

Edit: Ok, found the problem. Seems like I have accidentally unsoldered R2 when I removed the light sensor. From your pictures I found out, that there has to be a 470k resistor. Now it works. :)

[LastSamurai]

@Yveaux Short question: the zener diode only caps the voltage of the trigger so that the atmega328 can read it safely, right? Wouldn't a 3.3V zener diode work just as well then? Only asking because I am currently having a hard time finding a matching zener diode on aliexpress.

[AWI]

@LastSamurai As long as you can be sure the Vcc of the Arduino stays around 3.3v you can use a 3.3v zener. If you power as indicated (2 AA cells) voltage can drop below 2V and that cannot be considered safe. As an alternative to the zener you can have a resistor voltage divider (or stack a few normal diodes).

[Marek]

Works like a charm!

[Yveaux]

@marek great to hear! :+1: