You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! I'm wondering whether it would be feasible to add nRF53 support to BMP.
The nRF5340 is a little bit different than the others though, so I'm not sure if this is compatible with BMP's architecture:
the two cores have private flash areas that need to be programmed from the respective core
the network core needs to be powered up by the application core
the AP of a core is disabled when APPROTECT is active
APPROTECT is activated automatically if the program doesn't keep it off
Nordic-specific CTRL-APs need to be used for unlocking
supporting only the application core is not an option since BLE can only be done by the network core and that is the main feature of the SoC
The text was updated successfully, but these errors were encountered:
👋🏼 It's nice to see some help showing up from one of the vendors for once 😄
So:
When BMD discovers the target, it will find each core individually. If there's a way to tell which core is which, the probe routine can register just the Flash region for that core with the target structure representing it.
If the application core is discovered first, the probe routine can, just as with the Flash, do core-specific actions such as powering up other cores - APs are discovered and probed sequentially, so as long as AP0 can bring up AP1 (for example), then BMD won't notice the changing environment and discovery will work how you'd hope.
That's unfortunate though, if we can identify a nRF53 device from the DP information or otherwise inject AP preparation somewhere in
then as long as the debugger is able to re-enable the APs, that's solvable.
That's rather more awkward
Where are those in the AP sequence? If we can identify an nRF53 part from the DP information such as the DP TARGETID register, or via the ID information (IDR, any other specific identification registers Nordic implements in their CTRL-AP register space) of those CTRL-APs, that can be solved for. It's a bit more awkward but not impossible to go back and re-evaluate an AP if the CTRL-APs come after the core ones.
Hope that helps, and we'll be happy to provide a guiding hand and advice if you're able to contribute an implementation for discovery of nRF53 devices. Our feature/64-bit-cortex-support branch is probably highly indicated to be merged before this though due to all the fixes it does to
Hi! I'm wondering whether it would be feasible to add nRF53 support to BMP.
The nRF5340 is a little bit different than the others though, so I'm not sure if this is compatible with BMP's architecture:
The text was updated successfully, but these errors were encountered: