Detailed description
This PR adds support for the Nordic nRF53 series (currently just the nRF5340) microcontrollers, which is a dual core SoC with one application and one network Cortex-M33.
It implements the nrf53 target driver plus the standard probe iwring, following the conventions of the existing nrf51, nrf54l and nrf91 drivers.
For each core it provides
- The memory map (flash, UICR, RAM) and NVMC flash + uirc programming, so gdb load works on both cores.
- A per core mass erase via the NVMC ERASEALL register, so
monitor erase_masson an attached core erases that core (and only that core)
Since the nRF5340 uses hardened APPROTECT, a protected core's AHB-AP does not enumerate, such a core is surfaced as a fake AP target (following the nRF52/nRF54L drivers) whose monitor erase_mass runs the CTRL_AP ERASEALL plus APPROTECT-disable sequence to recover it. A rescan then brings the core up as flashable.
Some further nRF5340 behaviours are handled in the driver:
- The network core is held in RESET.NETWORK.FORCEOFF until the application core powers it. A DP prepare hook releases FORCEOFF through the application AHB-AP before the AP scan so that the network core enumerates in the same scan.
- The nRF5340 returns outdated/stale data on the first AP read after a SELECT/bank change, so the driver installs a double reading dp -> ap_read for the nRF53 DPs
It also adds a monitor read command exposing the FICR device information (which may be useful) since the nrf51 has a similar command.
Tested on an nRF5340 module (Panasonic PAN1783) over a Black Magic Probe v2.3c.
Your checklist for this pull request
- I've read the Code of Conduct
- I've read the guidelines for contributing to this repository
- It builds for hardware native (see Building the firmware)
- It builds as BMDA (see Building the BMDA)
- I've tested it to the best of my ability
- My commit messages provide a useful short description of what the commits do
Closing issues
Implements feature requested in issue #1779.