The dependencies should be between targets, not between commands and files.
Target dependencies on commands are not what they seem to be, and don't work.
Also see question, answer and comments on https://stackoverflow.com/questions/4010212/cmake-struggling-with-add-custom-command-dependencies
Replace constant value for IMAGE_HEADER_OFFSET by linker supplied value
This should make it easier to modify offsets without breaking stuff.
Various uses of IMAGE_HEADER_OFFSET could be simplified further.
Deleted bootloader.ld and combined.ld, they are not used.
As ${APP_BIN} and ${APP_HDR_BIN} are not true targets, the dependency on them
effectively only required the .bin files to be present.
When building with make -j, this led to the situation that the target
${NAME}_hdr finished *before* compiling the project, in case there were .bin
files left from previous builds, leading to ${NAME}_hdr.bin files containing
invalid CRCs.
Setting the dependencies on ${NAME} fixes this issue. The reasoning is that if
target ${NAME} is built, ${APP_BIN} should have been generated. There is no
need to depend on both ${NAME} and ${NAME}_hdr, as ${NAME}_hdr already depends
on ${NAME}.
CMakeLists.txt: let picowota_build_combined add files to clean target
We observed strange issues that (among other things) revealed that make clean
did not really make things as clean as it could. This is an attempt to clean up
various files generated.
This allows to choose, when running cmake, whether the bootloader will connect to an existing AP (default behavior)
or fire up its own (by passing -DPICOWOTA_WIFI_AP=1) by using the same provided credentials.
DHCP requests are handled, with these settings the subnet is 192.168.4.1/24.
main: Wrap flash commands in critical section and enable them
It works! Unceremoniously bailing out on the WiFi driver without
shutting it down might not be great - handling the "GO" and "REBOOT"
commands gracefully in the main loop would probably be better.
But hey, it works!
...but not it's obvious - we can't assume each packet nicely
encapsulates a single stage, it might all arrive in one go.
So the current "recv" implementation can't work. d'oh!