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>
- nRF21540 Front End Module Development Kit board definition
- nRF52840 MCU definitions based on nRF52840 Devkit files
Signed-off-by: Karol Lasończyk <karol.lasonczyk@nordicsemi.no>
Martí Bolívar