The erase mode for any external memory that is mapped to the address
space of the MCU is derived from the internal non-volatile memory erase
mode. In order to allow users to override the default value, add a new
--ext-erase-mode command-line option that takes an erase mode just like
--erase-mode does.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Instead of providing an `--erase-pages` command, generalize it to a new
`--erase-mode` one that can be set to `none`, `ranges`, or `all`. This
gives the user full control over the erase mode that will be passed on
to nrfutil.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The Nordic nRF54L series ICs use RRAM instead of flash. This implies
that erasing the internal storage before writing the new firmware is not
required anymore (unlike NOR flash, which does).
Note that RRAM on nRF54L devices is not physically paged, and paging is
only artificially provided, with a page size of 4096 bytes, for an easier
transition of nRF52 software to nRF54L devices.
In order to speed up the flashing operation and avoiding doing wasteful
write operations on the RRAM, default to ERASE_NONE for ICs in these
series.
A new ``--erase-pages`` command-line switch has been added to allow
users to keep erasing the pages that will be written to the firmware.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
In order to enable the use case where the underlying flash tool supports
bulk-flashing using multiple device IDs, augment the core runner class
with this new runner capability and implement it in the nrfutil runner,
since the nrfutil tool supports it natively.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Both backends supported as runners for nRF ICs, nrfjprog and nrfutil,
support erasing external memory as part of the programming operation.
Before this patch, and when the firmware was detected to be partially or
fully placed in external flash by inspecting the .hex address range, the
runner would instruct the backend tool to fully erase the external
flash (but the nrfjprog runner would ignore that, always erasing only
the sectors required). Instead, correctly default to erasing only the
sectors that are required to program the new firmware image in both tools,
and erase it completely only when the --erase flag is provided by the user.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The Nordic nRF52 series have a peculiarity that is not shared with any
other Nordic families of SoCs: the reset pin can be reconfigured as a
regular GPIO. This has an unintended consequence: if the user has
reconfigured the pin in Devicetree to be a GPIO, `west flash` will
override that and configure the IC to use it as a reset pin, and the
firmware at boot won't be able to switch it back to GPIO, because that
requires a UICR erase. This behavior is very confusing to users, because
the GPIO does not work at all, since it is now just a reset line.
With this patch, `west flash` defaults to using soft reset instead of
pin reset for the nRF52 family of devices, to avoid overwriting the
reset pin configuration that the user includes in the image.
In order to be able to continue to use pin reset for users that so
desire it, a new option `--pinreset` is added that forces the use of pin
reset. The existing `--softreset` option is left exactly as it was, but
it is now applicable only to families other than the nRF52.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The `erase` command was being used but there was no "backend"
implementation for it in nrfutil nor nrfjprog. Simplify the syntax and
implement it for both tools.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Instead of pre-generating the JSON batch to then execute it, use
command-line arguments and --x-append-batch to generate the JSON file
tht will then be passed to x-execute-batch.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The current option used as an example, --recover, is actually a separate
option in the runner itself. Instead use --clockspeed as an example,
which is applicable to all nrfjprog commands.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Allow for users to provide a --qspiini parameter that is passed directly to
the nrfjprog executable but only in the --program operation. This is
required since e073210ec2 enabled the
-O/--tool-opt for all operations, but --qspiini is only allowed combined
with --program.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
nRF54H can only be flashed using nrfutil now, so some workaround present
in the nrf_common module are no longer needed, e.g. UICR erasing.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Add basic support to flash application and/or radio core for nRF54H
series. Note that features like merged hexes present in nRF53 series is
not supported.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
On some new SoCs, the erase option is not required, so introduce a new
option that doesn't set any erase mode.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Some of the runners in the tree have been adding their own,
class-specific versions of a switch to instruct the runner to reset or
not the device after flashing.
In order to better support multi-image builds that require more than one
flash operation, introduce a new --reset,--no-reset command-line
parameter that is part of the RunnerCaps so taht this functionality can
be accessed in a standardized manner.
Implementations for the new parameter are provided for the runner
classes that were already configurable in this regard.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Standardize to nrfutil error codes instead of nrfjprog ones. This is
because nrfutil has a wider range of functionality and will eventually
be the default runner for all nRF devices. It is also consistent with
the internal operation representation, which is now using the nrfutil
format already.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Pass on the tool-specific options to nrfjprog during all operations, and
not only when programming. This is useful when combined with options
like --ip, that allows west flash to be used over the network.
Fixes#55340.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Generalize the logic that was previously in nrfjprog.py into a new
nrf_common.py, which can then use specific tool subclasses, one of which
is nrfjprog.py, to implement the actual tool invocation.
This commit lays down the groundwork for the addition of a new backend
for nRF boards, the new nrfutil tool from Nordic. Both nrfjprog and
nrfutil will coexist in the immediate future, but nrfutil is expected to
be the sole tool for everything nRF in due time. This is why the internal
representation of the operations is based in JSON and is using the exact
format that nrfutil expects when using the 'execute-batch' option, that
takes a JSON file with an array of operations to be executed.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This is a partial revert of commit
2cee5ff519
("scripts: west_commands: runners: remove deprecated options").
I remarked at the time that the removal of the older way of writing
things from the runners themselves seemed gratuitous since they are
easy to continue to support indefinitely and people may have been used
to the old way of doing things. It didn't seem worth the fight to push
for a revert at the time, though.
Since then I've run into real problems that their removal has caused
in the wild and I am convinced that this part of that patch was wrong.
Restore the original, undeprecated forms of these options, but make it
clear in the command line help that they're just obsolete alternative
spellings at this point.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
The --snr (nrfjprog) --id (jlink) and --board-id (pyocd) options were
deprecated a long time ago in favor of --dev-id. It is time to remove
them.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Currently, it is not possible to use a normal flash command to flash two
hex files that contain data in the UICR region, even though these
data don't conflict with each other.
However, that is not a technical limitation of the device, but of the
nrfjprog runner as it fails as soon as the hex file contained UICR data
and there was no --force/--erase/--recover used.
That approach was used in the past as program operation was used
without --verify, but as this option was added a while ago it is an
unnecessary limitation.
If the UICR wasn't erased before programming, the verify of the program
operation will now fail, so giving the user a warning in this case that
the hex files contain data in the UICR will still give the user a hint
of what might have caused the failing verify.
Additionally, it enables partial programming of the UICR without the
use of the --force option.
Signed-off-by: Markus Swarowsky <markus.swarowsky@nordicsemi.no>
The --tool-opt runner option is the recommended practice for allowing
runners to take additional arguments that are passed on to the
underlying tool. It exists because we don't want to add one runner
option for every single tool option that users might want to tweak --
that would be a nightmare.
Enough runners are using this option that it's time to promote it to a
common runner capability with consistent behavior, the same way we did
for the --dev-id option in the past. This removes boilerplate from
individual runner files and ensures consistent argument handling for
this option when it is supported.
Since --tool-opt is a bit long to type, and we've had some complaints
about that, take this as an opportunity to standardize on -O as a
short option equivalent for it.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
When a hex file contains some data that needs to be programmed using
the QSPI peripheral (because it targets the XIP region), nrfjprog
needs to be provided with an option that specifies the QSPI erase
method to be used (otherwise, reprogramming will fail).
This commit adds the "--qspisectorerase" option when needed and it
also fixes the programming routine for nRF53, so that data for the
XIP region is not incorrectly interpreted as intended for the network
core.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
nrfjprog prints out a warning if a device is programed without the
--verify option, which can be confusing.
So added the option when programming with nrfjprog.
Then west flash can be used without getting a warning.
Also changed the tests to only accept programming with --verify
option.
Signed-off-by: Markus Swarowsky <markus.swarowsky@nordicsemi.no>
In order to allow for further options to be deprecated with minimal
impact, add a deprecation argparse Action and a callable instantiator
that can be used to deprecate options in favor of new ones.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Set options that are definitely true or false to True or False in the
options dict. Add a 'getboolean' method that also allows a fallback to
False in case the option is not mentioned in .config due to unmet
dependencies. This allows calling code to just ask about the option
they are interested in, even if the .config file doesn't mention the
option at all.
Propagate this to users within the runners package and 'west sign',
taking advantage of the new build_conf property.
Rename the 'bcfg' internal variable in sign.py to 'build_conf' to
match other source files that use BuildConfiguration instances, to
make it easier to grep for users.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The commit fixes problem with nrfjprog runner for west flash,
that has been introduced with latest changes to BuildConfiguration
class.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
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>
The RunnerConfig class stores the locations of the Zephyr output files
in various formats (elf, hex, bin). A longstanding issue with the
representation is that these might not exist if the corresponding
Kconfig options are not set. For example, if
CONFIG_BUILD_OUTPUT_BIN=n, there is no .bin file.
Change this so the type system knows these are Optional[str], not str.
Fix the runners that use non-ELF outputs so they check for the
existence of the relevant file before using it, mostly using a new
ZephyrBinaryRunner.ensure_output helper.
I'm not going to bother with checking for the ELF file itself; that's
always there as far as I can tell.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
It's fine to flash an image with UICR data as long as the user has
given any of the --erase, --recover, or --force options. Silence the
error correctly.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Rework the runner to improve various issues.
Every board.cmake file for an nRF SoC target is repeating boilerplate
needed for the nrfjprog runner's --nrf-family argument. The
information we need to decide the --nrf-family is already available in
Kconfig, so just get it from there instead. Keep the --nrf-family
argument around for compatibility, though.
This cuts boilerplate burden for board maintainers.
We also need to revisit how this runner handles recovery to fix it
in nRF53 and keep things consistent everywhere else.
To cleanly handle additional readback protection features in nRF53,
add a --recover option that does an 'nrfjprog --recover' before
flashing. Keep the behavior consistent across SoCs by supporting it on
those too. Because this is expected to be a bit tricky for users to
understand, check if a --recover is needed if the 'nrfjprog --program'
fails because of protection, and tell the user how to fix it.
Finally, instead of performing a separate 'nrfjprog --eraseall', just
give --chiperase to 'nrfjprog --program' process's arguments instead
of --sectorerase. This is cleaner, resulting in fewer subprocesses and
avoiding an extra chip reset.
Having a separate 'west flash --recover' option doubles the number of
test cases if we want to keep exhaustively enumerating them. That
doesn't feel worthwhile, so update the test cases by picking a
representative subset of the possibilities. Each test now has enough
state that it's worth wrapping it up in a named tuple for readability.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Inspect the hex file with intelhex, and fail if the hex file has any
contents in the UICR area(s).
family == 'NRF52' still always does --sectoranduicrerase, but this
option is not available on other families.
Add --force command line option to proceed with flashing instead of
failing.
Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
This is needed for sanitycheck hardware maps which take the serial
number directly from USB metadata.
Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
Move the --erase option to core.py from nrfjprog.py and jlink.py,
where it is currently supported.
Using the RunnerCaps option enforcement mechanism introduced earlier,
enforce that it will only be given to runners that support it.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Require all implementations to provide a do_create(), a new
ZephyrBinaryRunner abstract class method, and make create() itself
concrete.
This allows us to enforce common conventions related to individual
runner capabilities as each runner provides to the core via
RunnerCaps.
For now, just enforce that:
- common options related to capabilities are always added, so runners
can't reuse them for different ends
- common options provided for runners which don't support them emit
sensible error messages that should be easy to diagnose and support
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We can just call super() instead of super(MyClassName, self). The
original extra verbosity is likely due to old habits of mine from
Python 2 which are no longer necessary, but got copy/pasted around.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This guarantees muscle memory will work over multiple runs when the
same boards are connected. (The "nrfjprog --help" output for --ids
does not guarantee an order.)
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Right now, the nrfjprog runner will prompt the user for which board to
use if there are multiple possibilities and the --snr command line was
not given to specify one ahead of time.
Tweak this so it only happens if standard input is connected to a
terminal. This should avoid stalling the process on board farms when
this runner is used in automation.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The create() classmethod should not be doing any I/O -- its only job
is to create the ZephyrBinaryRunner instance. It's currently trying to
figure out what the serial number of the board is, though. Let's defer
that work to do_run(), so it gets handled by run_common's exception
handler.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Carles Cufi
Pieter De Gendt
Gerard Marull-Paretas
Witold Lukasik
Marti Bolivar
Gerard Marull-Paretas
Markus Swarowsky
Andrzej Głąbek
Dominik Ermel
Øyvind Rønningstad