Skip to content
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

Add PSELRESET abstraction #405

Open
chrysn opened this issue Oct 13, 2022 · 0 comments
Open

Add PSELRESET abstraction #405

chrysn opened this issue Oct 13, 2022 · 0 comments

Comments

@chrysn
Copy link
Contributor

chrysn commented Oct 13, 2022

Since #136 there is an abstraction for the "customer storage" parts of UICR, but that register block also has other registers, most prominently PSELRESET which guides the use of the reset pin.

Having them mapped out would be useful in debugging why resets don't happen the way I'd expect them to. (After an erase-all necessitated by some chip lock, UICR was reset and thus the reset pin was disabled).


TBH I'm not sure this is a good place to have this -- especially erasing UICR and writing again sounds like a recipe for desaster to me, given there's no double-buffering. It might well be that the most benefit of a function for accessign PSELRESET gives a user is to tell it that "this is primarily here for debugging; if you want to set it, you better do X".

And I don't know what X is -- right now I have a uicr_reset_pin21.hex file that I merge in with the produced code when I also merge in the softdevice. Possibly it would be within this crate's area to have some infrastructure like

#[nrf_hal::flash_time_uicc]
static UICC = nrf_hal::UICC::new()
    .with_psel_reset_pin(21)
    .with_psel_reset_connected()
    .with_nfcpins_protect_disabled();

but neither do I have a concrete plan for that, nor am I sure this works without additional magic in the linker script.

uicr_reset_pin21.hex
:020000041000EA
:0812000015FFFF7F15FFFF7FC2
:00000001FF
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant