Re: [OpenOCD-devel] NRF52840 approtect erase and unlock

[Tomas V. <to...@us...>]

Hi Pieter,

On 30/09/2020 16:39, Pieter De Gendt wrote:
> Hi,
>
> The following commit adds nrf52_recover to erase and unlock nrf52 
> APPROTECT
> https://sourceforge.net/p/openocd/code/ci/73a5f58adba73306b08b7bb22ff8a9511e79869f/
>
> However this doesn't seem to work for my nrf52840.
> There are multiple issues:
>
>   * Several calls are done to *ocd_$dap* which isn't a valid command,
>     just use *$dap*
>
Arghhh, the change was developed before the big series "Handle Tcl 
return values consistently "
http://openocd.zylin.com/1815 (when ocd_ prefix was necessary) and have 
been sleeping in Gerrit too long.

>   * *apreg 1 8* is read-only, but is written
>
It was intentional, with CTRL-AP RESET asserted I observed a strange 
behaviour of ERASEALLSTATUS  on some hw (nRF52832?)
If I recall correctly this worked as a workaround. If the register is 
read-only, the write is just a harmless no-op.

>   * *ERASEALLSTATUS* is compared to 1, while 0 is the value for ready
>
Good catch. Maybe also the reason of the previous problem.

I found interesting white paper
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fnwp_027%2FWP%2Fnwp_027%2FnWP_027_erasing.html

I'll try to implement the erase sequence as described in it (assert 
CTRL-AP RESET after erase, not before)


> I used the datasheet 
> https://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.1.pdf to verify 
> the values.
>
> I think http://openocd.zylin.com/#/c/5384/ is closer to a solution.
>
> Changing all this, however, still doesn't allow me to unlock the 
> controller as it restarts with approtect still active. Any suggestions 
> on how to proceed and debug?
>
Paradoxically after removing ocd_ prefix nrf52_recover worked for me on 
a locked nRF52832.
I let you know as soon as I finish the fix.

Tom