OTA FW update using I2C EEPROM



  • Hi,

    I have boards with I2C EEPROM (32 or 64kB) instead of a SPI flash already supported via dualoptiboot. Been looking a bit but haven't found any discussion about such so far? Sorry if I have missed one.
    I have both nRF24 and RFM69 radios in use and going to mysensors from my earlier proprietary system.

    Anyway I already started implementing changes to dualoptiboot and mysensors OTA code. IF someone knows of existing work please do point me there so I can stop working on it. My idea is to make a simple EEPROM (24(L)Cxxx) driver that looks like the SPI flash driver to make the changes to mysensors minimal. Seems so far only a few lines are needed in addition to the new driver. Bootloader is a bit more work. Any comments about this approach (in case it starts working well and someone else likes to use it) ?


  • Hardware Contributor

    @kisse66
    cool.
    so far only spi flash memory are supported. so, no i2c existing work for the moment i think 😉



  • It seems to work now. Boot loader needs some more work, but MySensors part should be usable. If someone likes to have a look you can find it at http://github.com/kisse66/MySensors fork. By default it still uses SPI flash and works just like the original. To use I2C EEPROM uncomment (MyConfig.h) or define MY_OTA_USE_I2C_EEPROM in your sketch. You'll need also MY_OTA_FIRMWARE_FEATURE of course.
    My code uses Wire library for I2C (new driver) and defaults to address 0x50 (real I2C address 0xA0) that most EEPROMs use I think. EEPROM has to use 16-bit addresses, 24(L)C256 or 512 should work.
    Only tested with MYScontroller, pro mini 8MHz with nRF24 and 24LC512 EEPROM on AVR HW I2C.

    Do note that I'm still working on the bootloader part which you'll need to make this actually work. I have a "seems like working" hack, but it needs some more work. Approach is to use DualOptiboot code and add option there for alternate I2C. I'll publish it when it's getting a bit better.



  • Please correct the warnings at https://github.com/mysensors/MySensors/pull/834
    I really want to see support for eeprom in official mysensors.



  • kisse66: i have error while writing bootloader:
    avrdude: ERROR: address 0x8010 out of range at line 65 of ...optiboot_atmega328_e8.hex
    I compile it with Arduino-1.0.x
    Can you share a compiled file?



  • The bootloader at github is not verified yet, it's an updated version from pieces I used to test. That's why I haven't mentioned it yet here. Looks like linking adresses are wrong. Will fix but can't promise when. Might have time next week.

    If you need it now, try lowering the --section-start=.text=0x7c00 at Makefile line 618 to 0x7a00 (or down to 0x7800). The 7c00 only allow for 1kB bootloader. You also need to have fuses set for max boot block. Luckily they are so as default in many pro mini's at least.

    I'll see if I still have the binary I used. It's for 8MHz pro mini.

    I'm interested in hearing if it works on your case as well. I'll be doing some more testing also and update github accordingly.



  • I changed to 0x7a00
    FUSE: L:FF H:DA E:05 this is 1024 words bootloader.

    And beautifully everything works.
    With little attention, I do not know why MYSCOntroller has been sending firmware several times.



  • When eeprom ota will be attached to official development branch ?



  • kisse66: Can you refresh your sources? Official Mysensors has now added a very cool option: MY_SIGNING_SIMPLE_PASSWD.
    What determines the moment to add your changes to the official distribution?



  • It's up to the maintainers to decide if it's good enough implementation and then when to merge the PR. There has been no comments yet.

    I don't like to update my version now as it's pending.



  • I wish it was so long. You did a great job.



  • @kisse66 Excellent work - I have a few nodes with i2c eeprom waiting for MySensors to support it.


  • Hardware Contributor

    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 ?



  • @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.



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



  • @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?



  • 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


  • @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?



  • @kisse66
    This is not urgent.
    Nice holiday 🙂



  • 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!



  • @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.



  • 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!



  • @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).



  • @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!



  • @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).



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


Log in to reply
 

Suggested Topics

71
Online

11.4k
Users

11.1k
Topics

112.7k
Posts