OTA not working in my current setup (CRC Error)
As a some sort MySensors enthousiast I can't get OTA to work (ever).
I have a current setup with a Raspberry Pi 3B that is configured with an RFM69 radio and setup as MQTT gateway. I have multiple nodes setup and with MQTT is all works flawless.
So last december I wanted to take it to another level and get my nodes to OTA, but as of today I can't get it to work.
Anyway to make my nodes OTA I installed mycontroller.org and set everything up. I use EasyPCB boards with RFM69 radio's, and soldered AT25DF512C-SSHN-B on these boards. Burned the Dualoptiboot sensebender micro bootloader as instructed.
Started with a simple battery node (code from examples and added OTA).
Only to change the version number in presentation and compile and upload the HEX file to MyController. Instructing the node to upload the firmware always results in CRC error.
Node log using serial console:
178499 OTA:FWP:FW END 180334 OTA:CRC:B=04E0,C=5897,F=3E27 180338 !OTA:FWP:CRC FAIL
My question. Is there anybody how has this some problem? Or is having the same setup and do have a working OTA environment? I'm running Mycontroller 1.5.0 FINAL and Mysensors 2.3.2 code on both the node and gateway. And not having any luck using OTA. All the rest works as expected. Did found a lot of other topics but these where all old and fixed in later firmwares.
Thanks in advance.
I don't have experience with fota, but if you haven't already found it, https://github.com/mysensors/MySensors/blob/40f4deb18c49b1eb6b91f59e3602e9f5c56a2a1a/core/MyOTAFirmwareUpdate.h#L39 might make it a bit easier to interpret the log messages.
Yes I've seen MyOtaFirmUpdate.h and the log messages.
Did some calculations on the B/C and F line
109953 OTA:FWP:FW END 111788 OTA:CRC:B=04E0,C=5897,F=3E27 111792 !OTA:FWP:CRC FAIL
B= Firmware Blocks, 1248 blocks (same value from MyController)
F= Firmware CRC 15911 (same value from MyController)
No the wrong one:
C= Calculated CRC 22679 that divers from Mycontrollers 15911 value.
But I can't figure out what causes these calculated crc errors. Well I know how CRC is calculated, but now how do I figure out where the error is happening.
@VonJoost not sure if it helps, but defining OTA_EXTRA_FLASH_DEBUG (in the running sketch) ahould cause additional debug output that might give a clue.
Now I'm seeing
125540 OTA:FWP:FL DUMP 000A:00000000000000000000000000000000125546
These lines in the serial console and a lot of them. Don't know if these lines are any good.
18442 OTA:FRQ:FW REQ,T=0003,V=000D,B=0437 18466 TSF:MSG:SEND,45-45-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:03000D003704 18509 TSF:MSG:READ,0-0-45,s=255,c=4,t=3,pt=6,l=22,sg=0:03000D003704B0E2A1114FC0C40ED11C992309F45BC0 18520 OTA:FWP:RECV B=0437 18524 OTA:FWP:FL DUMP 437A:0000000000000000000000000000000018530
It get's a long line from recieve and just a small amount reads from flash?
Maybe replying at my own post.
But the MySensors OTA code uses
#define MY_OTA_FLASH_JDECID (0x1F65)
That is for the AT25DF512C-SSHN-B if i read the datasheet from Adesto right. But using code 0x1F65 always results in Flash INIT error and using 0x00 works. But that's the "unknown type".
cabat last edited by cabat
May be it's help you - in my case with Winbond W25X40CL changing code in SPIFlash.h solve the problem with CRC error:
i change this:
#define SPIFLASH_BLOCKERASE_32K 0x52 //!< erase one 32K block of flash memory
#define SPIFLASH_BLOCKERASE_32K 0xD8 //!< erase one 64K block of flash memory
@VonJoost - there are a known bug in EasyPCB with external flash. Check you dont have boards with this bug. (Not even sure you are using external flash, but just what came up when i read the thread)
cabat last edited by
@VonJoost I see in serial console about the same picture - dump is 000000....
So my next step is to solder the SCK pin. Will do that in a few days. Keeping everybody in the loop.
Okay, i understand there are some bugs in the PCB design. Having V10 boards I have tried to do a quick fix and solder the SCK pin.
But still getting CRC errors. Should I do more more modifications? Or abandon the EasyPCB boards because of the bugs with the flash memory and get some other PCB to try again?
@VonJoost - bug can be read about here: https://forum.mysensors.org/topic/2740/easy-newbie-pcb-for-mysensors/666
Yes, SCK was not connected but as I said, this was fixed and new gerber has been published. I dont know what CRC errors are but if you had the issue with no connection and fixed it EasyPCB should work just fine. You should be able to check continuity with a multimeter.
I've been reading and measuring and soldering everything to fix the bug. With some datasheet help and my trusty multimeter. I did the following fix:
Soldering the SCK pin (only soldering this pin does not fix the CRC errors)
Soldering pin 7 to pin 8 on the flash chip finishes the fix.
So first my log shows:
OTA:FWP:FL DUMP 437A:0000000000000000000000000000000018530
Now the log shows
TSF:MSG:READ,0-0-45,s=255,c=4,t=3,pt=6,l=22,sg=0:03000D0003000C94D5030C94D5030C94D5030C94D503 OTA:FWP:FL DUMP 003A:0C94D5030C94D5030C94D5030C94D503127516
Lot more data is whriting to the flash.
And after the firmware is recieved:
127760 OTA:FWP:FW END 129652 OTA:CRC:B=04E0,C=3E27,F=3E27 129656 OTA:FWP:CRC OK
And the node reboots so OTA works!
And as a bonus
#define MY_OTA_FLASH_JDECID (0x1F65)
Works also so this can also be used as an red flag if your OTA is not working and you have the correct flash chip but get a FLASH INIT error.
I would like to thank everybody for helping!
@sundberg84 I would not move away from your great PCB design, but I might order some new ones.
cabat last edited by cabat
I want to share an interesting case about updating the firmware over FOTA..
I have several nodes on a RS485 bus with memory chips.
Recently I decided to update the firmware on several at once and ran into an unexpected problem - repeated attempts to update constantly ended up with a checksum error !OTA:FWP:CRC FAIL.
At the same time, I usually test all new nodes for FOTA firmware updates before installing.
I tried to understand what the problem might be and came to an unexpected result - in my case, disabling the directive OTA_EXTRA_FLASH_DEBUG, which I had been using for a long time, when I first tested updates, helped.
After disabling this directive, all firmwares were updated the first time. Very strange, but nevertheless ...