Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Ivan Grokhotkov
@igrr
Just rounding the sketch size up to 16 bytes will not give a correct result when pos is already 16 bytes aligned, I.e. you need to take checksum byte into account.
P.s. I can send you a sketch which is 16 bytes larger than get sketch size 😉
Martin Ayotte
@martinayotte
BTW, I don't know about all underlying stuff, but if getsketchsize() isn't able to keep track of the real size, why not padding empty words with some signature such 0xAAAAAAAA that getsketchsize() will be able adjust itself to real value ?
Ivan Grokhotkov
@igrr
It's not that it can't track the real size... it's just a bug and the fix is basically one extra line which i have posted above.
sticilface
@sticilface
A checksum now it makes sense. Thanks. I'll adjust, test accordingly and amend the pull request.
Ivan Grokhotkov
@igrr
I'm on it already :)
wait a bit please...
Ivan Grokhotkov
@igrr
actually, if you don't want to be bothered with flashRead and getting all alignments right, you can simply use memcpy_P to copy stuff from flash to RAM
it will be a bit slower (around 35% slower), but not a deal breaker.
turned out, writing a test case for getSketchSize and getSketchMD5 is not exactly trivial...
Me No Dev
@me-no-dev
:D
how long does it take to calculate the md5?
Ivan Grokhotkov
@igrr
~100ms with flashRead, ~135ms with memcpy_P
that is for a 230k sized sketch
flash read methods are blocking, so you can not actually do calculations while you wait for data to be pulled from flash.
but meh, it's caching result anyway, so it's just 100ms once, not a big deal
Me No Dev
@me-no-dev
maybe not a bad idea to use the code to check the md5 of the new uploaded sketch (instead of checking what came through the network)
currently we do not know if the sketch was written properly
Ivan Grokhotkov
@igrr
yeah, possible entirely, just read stuff back in UpdaterClass::_writeBuffer...
Ivan Grokhotkov
@igrr
i have no idea how to test this though
i.e. how to simulate a case when flash is not written correctly
Me No Dev
@me-no-dev
pick a random address and write something else to it?
how are you testing the flashing now?
write to a file?
Ivan Grokhotkov
@igrr
no i mean i wanted to write a test case for this feature — checking that md5 catches bad flash writes
we don't have one at the moment, so would be good to add it
Me No Dev
@me-no-dev
since it's a test, it does not involve a real ESP right?
Ivan Grokhotkov
@igrr
it does
Me No Dev
@me-no-dev
hmm... then...
Ivan Grokhotkov
@igrr
i think i'm going to take my FPGA board and create a flash chip emulator with a "bad block"
should be fun
Me No Dev
@me-no-dev
:D
so if you OTA a sketch, the md5 is once checked for the incomming data
if you write some random stuff to a random place after that
the following md5 will fail
that only if md5 is checked once the new sketch is written to the flash and not while writing it
or am I getting the totally werong idea of how tests work
Ivan Grokhotkov
@igrr
actually i added flash read back thingie into the Updater, so MD5 is calculated by Updater based on data read from flash.
esp8266/Arduino@0c58dc1
Me No Dev
@me-no-dev
why not use both and know which one failed?
I mean network or write
Ivan Grokhotkov
@igrr
does it matter?
like, does it matter which one failed?
Me No Dev
@me-no-dev
it could... but more for debugging
if you get fails, you will need to add it so you can figure out where to look for issues
it can hint on failing flash blocks also
Ivan Grokhotkov
@igrr
yeah, that can be done basically by comparing the contents of _buffer written and read in _writeBuffer, that will give you info on exact location in flash where this happens
Me No Dev
@me-no-dev
maybe even retry write?
Ivan Grokhotkov
@igrr
if the flash is borked i wouldn't like software to sweep the issue under the rug by doing some retries.
just fail hard and fast