This approach is less intrusive than merging the entire application into one binary
implemented in #006d64e8b268e479703a0aac7eed8bef1ebea587
In this implementation we safely copy the required bootloader binary to the
build directory, adjust the headers via esptoolpy and the "merge_bin" command
according to --flash-size and --flash-mode arguments.
Resolves#872
Arduino core v2.0.4 contains updated bootloader images that have innacurate default headers. This results in bootloops if firmware is flashed via OpenOCD (e.g. debugging or
uploading via debug tools). For this reason, before uploading or debugging we need to merge all binaries (firmware, bootloader, partitions, etc.) via esptoolpy so that
the image headers will be adjusted according to --flash-size and --flash-mode arguments.
Note that this behavior doesn't occur if uploading is done via esptoolpy, as esptoolpy overrides the binary image headers before flashing.
- Add extra data to "projenv" as well so that the extra data it can be overridden after the BuildProgram routine
- Use the new INTEGRATION_EXTRA_DATA env variable instead of IDE_EXTRA_DATA
Recent versions of ESP-IDF have a bug in which the Backtrace: line is
malformed.
Old/Good: Backtrace: 0xN:0xM 0xN:0xM 0xN:0xM ...
New/Bad: Backtrace:0xN:0xM0xN:0xM 0xN:0xM ...
I issued https://github.com/espressif/esp-idf/pull/9138 against
ESP-IDF to fix the underlying problem, but it is unclear when or if
that PR will be accepted, especially since the monitor program in
ESP-IDF is immune to the problem.
By using a decoding technique similar to the one in ESP-IDF's monitor,
either backtrace format can be accepted.
Supersedes #687 , which does not quite work, in that it misses one of
the entries.
Valerii Koval