OTA FW update using I2C EEPROM

[Nca78]

Wow, great job, thank you @kisse66 !
Any limit in the size of the memory chips ? Like is it a problem if I use a 256/512k version ?

[kisse66]

@Nca78
Good question - Have only tested 256 and 512kbit (32/64kB), nothing bigger than 64kB. Unfortunately I2C protocol is slightly different between different EEPROMs, so code does have limitations. There's two sides of it. MySensors side now uses extEEPROM underneath, so what it supports should work. Address type is 32-bit, so the interface supports >64kB. Haven't checked the code, but at least it defines 2Mbit type (see extEEPROM.h). My patch now assumes EEPROM is 32kB (64 fine) as it's enough for mega328.

Bigger issue is the bootloader, which has more assumptions. Likely not working as is for anything bigger than 64kB. Would be interesting to hear if someone can try, I don't have larger EEPROMs.

[melwinek]

kisse66: Arduino with this bootloader without connected EEPROM hang in bootloader with DEBUG: SSF2

[kisse66]

@melwinek
hmm, interesting. There should be a timeout, but I need to re-check. Are the I2C pins floating or are the pullup resistors still there?

[melwinek]

kisse66: Bootloader hang only when i disconnect pullup.

1. Pullup and EEPROM - OK
2. Pullup without EEPROM - OK
3. Only EEPROM - Hang
4. Free I2C pins - Hang

[kisse66]

@melwinek
Thanks, good info. Middle of vacation activities here but I looked the code a bit more. It does have the retry limit, but also forever loops with certain I2C events. Can be fixed quite easily I believe. I need to setup test bed for it to see myself.

Not an urgent thing I believe?

[melwinek]

@kisse66
This is not urgent.
Nice holiday :)

[manutremo]

Hi, I just wanted to report that I was able to compile and use the dualoptiboot bootloader with I2C support on a Mini Pro 8MHz board with an I2C AT24C256 breakout board and a RFM69HW radio. With this setup I've been able to to update several sketches via OTA using MysController.

I took me some time to understand the workflow and necessary tools since I wasn't able to find a complete, up to date tutorial. Specifically, it took me some time to find out that the compilation of the bootloader with the Arduino IDE requires downgrading to version 1.0.6.

I also run into some issues with the Arduino IDE not being able to find the extEEPROM.h file (even though it was indeed present at the correct location), and having to copy the i2c.h file to the optiboot folder in addition to the optiboot.c and the Makefile files.

Also, I finally managed to flash it using avrdudess since I was getting errors when trying to use the IDE.

So even though the author above that this bootloader isn't yet finished, it's working properly. Granted that I haven't tested it thoroughly under all scenarios, but it certainly looks promising. Can't wait to see it fully implemented in the mysensors framework. I'll continue reporting any additional findings.

Many thanks!

[kisse66]

@manutremo

Good to hear. I'm aware of one issue only as described above by @melwinek, haven't found time to fix. So "seems to work", but have done limited testing.

Yes, you need older Arduino IDE version. I have actually two versions installed, latest and 1.0.6. Using latest for all except bootloader.
I don't have to copy anything, I just cd to the bootloader located under old arduino tree (git cloned to Program Files (x86)\arduino-1.0.6\hardware\arduino\bootloaders\DualOptiboot) and do

omake atmega328_e8

from windows cmd prompt.

This is forked from mysensors bootloader, maybe it could be merged back there some day with step by step instructions.

[manutremo]

Hi @kisse66!

More testing and still working fine... the only issue is still the one reported by @melwinek.

Any chance that you may be able to hace a look? Or alternatively I might be able to try myself if you guide me a little bit on where should that timeout be in the code... :)

Many thanks!

[kisse66]

@manutremo

been quite busy lately, can't promise anything but I'll try. It is an issue, but I don't think it's very urgent since if one uses I2C bootloader at least the pullups should be there.

I was thinking of two things to try. Perhaps enabling the internal pullups may help (need to check if it works when TWI is enabled) or better fix the forever loops in the I2C code. There's already some retry counters for errors, but not everywhere. I guess when the pullups are not there TWI controller gets weird states and the code just loops retries somewhere. So perhaps add a counter to all the retrys (several locations in i2c.h, begin-label at readbyte would be my first choice. restart-label already has a counter).

[manutremo]

@kisse66 Many thanks for the guidance. Yes I see what you mean. I suspect that the program gets stuck in one of the while

while ((TWCR & _BV(TWINT)) == 0) ; /* wait for transmission */

blocks when something weird occurs with the communciation thorugh the I2C bus. I'll fork you're code ad try to include some timeout condition so the sketch ca run even whe the I2C or the memory itself is not working correctly.

It is my understanding that the I2C bus should always have those pullups or there is a risk that the signal ends up floating. Anyways, I'm using a break board which already contains the proper pullups - in my case the problem was a deficient wire.

Thansk again for your work!

[manutremo]

Hi,

I just submitted a pull request with the necessary changes to implement timeouts in the wait loops.

I hope it works!

[kisse66]

@manutremo

now merged, thanks!

So this should fix the bootloader hang without pullups. The binary got a bit bigger again, but does not change much of anything since it still fits into 2k (1024W).
I tested it with 8 and 16MHz pro mini with a few different EEPROMs (256 and 512kb).

[manutremo]

You're very welcome @kisse66 I hope others find this useful too!