The nrfjprog utility is not capable of flashing a hex file which affects the flash memories of both coprocessors of the nRF53 family of SoCs. However, the user is capable of creating such a hex file using the HEX_FILES_TO_MERGE build system variable. An example use case is to build a bluetooth controller application for the network core, then use the zephyr.hex file in that build directory as the HEX_FILES_TO_MERGE argument for a separate Bluetooth application build targeting the app core. Work around this by detecting the situation and doing the right thing by splitting the hex file back up again, even if thats a bit awkward. Splitting the hex into app and network core components allows them to be flashed separately. This is the only way we can get the job done with nrfjprog. This is arguably nicer since there's just one 'west flash' invocation. At least in the use case named above, you wouldn't need to rebuild the controller application very often, so this is a simpler user workflow. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no> |
||
|---|---|---|
| .. | ||
| nrfjprog | ||
| conftest.py | ||
| test_blackmagicprobe.py | ||
| test_bossac.py | ||
| test_build.py | ||
| test_canopen_program.py | ||
| test_dediprog.py | ||
| test_dfu_util.py | ||
| test_imports.py | ||
| test_mdb.py | ||
| test_nrfjprog.py | ||
| test_pyocd.py | ||
| test_stm32cubeprogrammer.py | ||
| test_stm32flash.py | ||