-
-
Notifications
You must be signed in to change notification settings - Fork 784
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nRF5340 support #1779
Comments
👋🏼 It's nice to see some help showing up from one of the vendors for once 😄 So:
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 Line 708 in e52eafa
|
I'm starting a new project based on that device and I'm really sad to not be able to use my BMPs. Could you please update this issue if there's some branch somewhere I can help with? Thanks! |
So, I never really played with firware programming using SWD, but I'm giving it a go and scratching my itch. It's early stage and probably not working, but in case anyone is looking: https://github.com/canatella/blackmagic/tree/nrf5430-support |
I updated the code, it now supports flashing the network code and I have some fixups. @maxd-nordic My device has never been protected so I didn't need to unprotected. Am I right that if the CTRL APP app protect and secure app protect matches the values in the UICR, I can assume its unprotected ? And if it is not, what am I supposed to do ? |
@canatella thanks for doing this! I didn't have the time myself. If you can do memory reads on the MEM-AP, protection is not engaged. I usually check the CSW dbgstatus bit of the AP. nRF53 has hardened APPROTECT. That means the chip will default into protected mode unless both UICR and firmware tell it to keep the debug port open. Most firmware will do this by default, but if you do an ERASEALL operation using the special CRTL AP, you can get there. The protection will not engage until you do a pin reset. You can flash firmware that keeps the port open or just unlock right before flashing your own firmware. Note that you need the app core to start the net core. Some extra info: In theory, there are also two other protection levels: SECUREAPPROTECT and ERASEPROTECT. The former allows you to only disable debugging secure mode stuff, while the non-secure domain can still be debugged. The latter is there to make it impossible to repurpose the chip after it was programmed. I recommend ignoring both of these, they only spell trouble. Also, block protection for flash blocks exists. Generally, CTRL AP ERASEALL solves any protection issues. If you enable ERASEALL by accident, the chip is fried. You might be lucky that it just looks like ERASEALL is enabled - we had that problem recently. If you use Nordic's official tools, we have a recovery operation which sets UICR and flashes a special firmware to both cores to keep the access ports open. |
@maxd-nordic Is the usual way of developing with this chip to build without APPROTECT for debugging and enable APPROTECT for production ? Or do people actually debug with APPROTECT ? In which case I guess you always need to do ERASEALL, flash and then debug without resetting. |
@canatella Often, it's not used at all. The intended purpose is to enable it in production builds of your firmware. Another option is to implement a feature in your firmware to disable APPROTECT on demand. A software authentication mechanism can be implemented to guard your secret firmware. |
Alright, thanks! @dragonmux, I have everything working but now I'm wondering what's the best UX. When the
And so nothing is displayed in the scan list. I can think of multiple ways to handle this.
Solution 2 might be the best as a user can put that command in the |
The way that this is done for other Nordic parts and others that implement similar kinds of access control is using a prepare function that detects the conditions for protection, and registers a fake target that when attached to, does the unlocking operation, or that when attached to can have You cannot run the erase before doing a scan not just because you won't have the DP, but because you won't even know what protocol to talk to the target or what the scan chain looks like. The RP2040 support has a kind of an example of how to go about what we're suggesting, if married with the nRF51/52 logic for determining protection. Note that you can have the detection occur before doing NB: Platforms are, in the context of BMD, things on which the firmware can run, not debug targets. It would be a target-specific command, not a platform command. |
I think you might be overthinking the problem, handling CTRL-AP ERASEALL the same way as it already is in nRF52 and nRF54L should be sufficient. The typical workflow when you encounter a locked target is like this:
|
@dragonmux , @zyp: It just feels a bit convoluted in regards to other tools. The Nordic tools, you just pass a flag and it does its thing. Same for probe-rs. What I did as a prototype for now is to define a custom command But I don't want to change things for the sake of it neither. If you think the fake target is more inline with the bmp workflow, I can do that. On the other hand, if you do feel that the global command could make the workflow easier, I'm willing to do the work, add a bit of infrastructure code so that it can be used in other targets and update the other nrf target to work like this, I still have some nrf52 boards somewhere. |
There are a couple of considerations at play here - first, other tools tend to be desktop-only programs while BMD runs as firmware first and foremost with a strict Flash constraint (128kiB for BMP); so many decisions about how things work are done to take that into account. Second is that because BMD is generally run as firmware and set-and-forget, being disconnected from and connected to new targets constantly without restart, any global state must be unsurprising in nature. We'd strongly suggest that a global that when run against a protected part just obliterates w/e was in Flash is extremely surprising, especially if, say, you set that global a week ago, forgot, and then went on to scan a part which you were wanting to do forensics on or otherwise analyse - you'd have just shot your foot clean off because of some global state which the probe will retain. This kind of thing is why it's done with a faked target so you have to consciously make the decision to erase everything. This is why other targets supported have commands to "enable dangerous commands" and such. Note that, in the flow where instead of having to Essentially what we're saying is that the philosophy is that any time you would do something destructive, it must be a conscious decision to avoid accidental damage, particularly if the user is doing exploratory stuff such as for failure analysis. This is the only counter we have to the very long runtimes probes see in the wild between restarts. All probe-side settings are essentially sticky. |
The implementation of the custom command probably doesn't use more memory than the fake target code. And for the long running scenario, you are right, it shouldn't create any surprise, but then resetting the variable after each use would do just that. But I don't really care, it's basically the same thing anyway. |
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: