OTA FW update using I2C EEPROM
-
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!
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 doomake 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.
-
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!
-
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!
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).
-
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).
@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!
-
Hi,
I just submitted a pull request with the necessary changes to implement timeouts in the wait loops.
I hope it works!
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). -
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).
