MYSController supports Sensebender Micro OTA FW updates

[scalz]

@tekka: yes, strange, but then it started.
@tbowmo: thx. I will try your code. CS on D8. My test breadboard:

I tried spiflash sample code in the lib. Init fail too, I needed to do this to have init ok. But when I hit 'i' for device it I get 0 or ff. And if I erase 'e' then read dump it seems that is not erased (I should see ff or 00 only I think).

//SPIFlash flash(FLASH_SS, 0xEF30);
//SPIFlash flash(FLASH_SS, 0x1F44);
//SPIFlash flash(FLASH_SS, 0x1F65);
SPIFlash flash(FLASH_SS);

Tomorrow I will recheck my breadboard and wiring. strange. I was just looking into Mysensors dev libs to learn how all is done when I saw your msg. thx

oh and I tried with 56k pullups too. nothing better...

[tekka]

@scalz said:

@tekka: yes, strange, but then it started.

I see, the OTA code should abort if the flash init fails. Will post a PR.

[scalz]

ok. so it seems to be an electronical problem. I have to get init ok. I will check this tomorrow.
So if I understand right, init was nok, but it transmitted all fw. and about the crc check error at the end. is it calculated from eeprom fw or during transfer in memory? I have not checked yet in the lib.

[tekka]

@scalz CRC is calculated from flash after all FW blocks are transmitted. In your case the FW blocks were not written resulting in CRC mismatch.

[tekka]

@scalz btw. is this s typo or are you connecting MISO to SI and MOSI to SO on the ext. flash? This may be the issue...

[scalz]

@tekka: sorry I think i don't understand? what is s typo, do you mean ref of eeprom (AT25DF512C-SSHN-B)? and yes MISO to SI on ext flash, MOSI-SO...is it wrong? how should it be?

[tekka]

@scalz have a look at http://forum.mysensors.org/topic/510/minimal-design-thoughts/25
MISO to SO and MOSI to SI

[scalz]

@tekka: waaw. too strong! I didn't see it! too bad :flushed: :flushed:. you saved me..tomorrow I will check all of this. thank you guys :thumbsup:
I think it will be ok now. Hopefully it was just my first batch and I have some changes, so. but it is good to know. next time I'll be much more careful. it's first time I use ext eeprom, so you are right about typo...

[tekka]

@scalz no problem. Good luck!

[scalz]

@tekka @tbowmo: I inverted MOSI and MISO wire on my breadboard. Now with SPIFlash example, it looks ok with Jedec id 1F65. So I retried ota (and I keep only gw.process in main loop now so transfer is faster of course). Unfortunately "fw checksum fail" at the end..
my log here if you want :logs1.txt
Maybe tomorrow I will be luckier and will find what happens now..

[scalz]

and now the good news for me is ... it is working, yeah! A small break with my mookjong, it gave me an idea:smiley:. And if my previous mistakes have done wrong config in eeprom???maybe I am wrong, but I have changed eeprom and ota is working very well now! So cool!
thank you for your patience...

[tbowmo]

Good to hear @scalz, congratulations on getting it to work :)

[scalz]

yes, I am very happy. I can finish the design of my ultra low power node now! it is a camel like (sub-uA) :smiley:

I have just a last question for @hek about ota:
I looked into the lib. And of course, ota is not interfered by sleeping. But it can be interfered by some process in main loop like sensors, delays... And it can take very long time for ota in these case if we don't optimize our loop. It is logic I understand. So I am looking for a way of preventing this because for a battery-powered node it could be problematic to have an ota transferring for minutes (15min for DHT sketch for example).

I saw you use fwUpdateOngoing for this in class, and it is protected, and I understand why. But it could be useful if we could have read access to it like a Get/IsOtaPending() Method. Just a get, not a set of course. Do you think you could add this feature? Or do I need to make my own class and derive it from Mysensors class?
Just a thought...What do you think about this?