Open nordicjm opened 2 years ago
CC @tejlmand @mbolivar-nordic probably need to plan how this works in future
this is not a bug, but using runner specific arguments on multiple domains are considered experimental at current stage.
There was however a flaw in warning printed, that it was not printed until 2 or more arguments were used.
See #50422
closed, as this is experimental feature, and the issue regarding correct printing of the error message has been fixed here: #50422
Reopening this as this is becoming a big problem with sysbuild, there are 2 issues here:
west flash
in a sysbuild-configured project need a level of granularity, if a device ID is provided, should this be provided to all runners? This will work if sysbuild is working with 1 SoC on 1 board, but if there are 2 SoCs/boards then this is wrong and going to fail. The other issue is the --recover
argument which is used to erase the contents of the flash, using the nRF5340 example, in a normal non-sysbuild project, this works as expected, but in a sysbuild project this supplies the argument to every image that is flashed, which means if you flash 3 images, it will recover, flash image 1, recover, flash image 2, recover, flash image 3 - leaving the board in a non-working state. So if this command is used, it should be used from a "global" perspective in sysbuild projects, recover all boards/cores when the script runs without running it once per flash invocation.in a sysbuild project this supplies the argument to every image that is flashed, which means if you flash 3 images, it will recover, flash image 1, recover, flash image 2, recover, flash image 3 - leaving the board in a non-working state.
Two years have passed. This is a very annoying issue. Have you found a solution?
in a sysbuild project this supplies the argument to every image that is flashed, which means if you flash 3 images, it will recover, flash image 1, recover, flash image 2, recover, flash image 3 - leaving the board in a non-working state.
Two years have passed. This is a very annoying issue. Have you found a solution?
It's been fixed for ages https://github.com/zephyrproject-rtos/zephyr/pull/69748
in a sysbuild project this supplies the argument to every image that is flashed, which means if you flash 3 images, it will recover, flash image 1, recover, flash image 2, recover, flash image 3 - leaving the board in a non-working state.
Two years have passed. This is a very annoying issue. Have you found a solution?
It's been fixed for ages #69748
Great. Thank you for pointing to this feature. Now, I have the west flash erase issue with an MCUBoot sysbuild application, which still does unwanted repetitive erasing & reset. I will try to find a solution using the provided information.
Describe the bug Issue noticed whilst testing https://github.com/zephyrproject-rtos/zephyr/pull/49552 It seems that with a sysbuild project, with multiple images e.g. sample application and mcuboot, using
west flash --recover
will wrongly have the west flash runner recover the module for every instance it is used, which results in a non-working board. It also resets the board after each programming cycle, which can cause issues if e.g. readback protection is enabled or if an application needs something else to start, in which case the following programming cycles will fail. Output:To Reproduce Build PR sample application for an nrf5340-based board and manually run
west flash --recover
in the build directoryExpected behavior One recovery - at the start of the programming process. One reset - after all images have been programmed.
Impact Showstopper
Environment (please complete the following information):